![2015-2016 Georgia Tech Team ARES
Critical Design Review
Page 73 of 92
5.7.2. RES Lifting Test
The main purpose of this test is [Appendix XX] to ensure the RES mechanism has the ability to
lift. the launch vehicle, to ensure the cable and framing is safely stabilized, to ensure the individual
components (this includes the stepper motor, the motor casing, the spool, the pulley, the cable, and
the eye screw) are durable enough to withstand the forces involved with lifting the launch vehicle,
to ensure the launch vehicle could be lifted in a safe but efficient rate of speed, and to determine
the most effective position for the pulley to be placed on the frame to yield the most torque on the
lifting rod.
During the testing, the RES will attempt to lift. the launch vehicle as quickly as it can as well as
hold the launch vehicle at different positions (15, 30, 45, 60, 85 degrees) in between the horizontal
and 5 degrees off of the vertical. It will help determine if the cable or frame needs more stability
support. If so, a guide will be added to the cable’s path and more framing will be added to the base
of the existing frame. The height of the pulley position will be varied during testing to determine
optimal torque. If the RES is not able to lift. the launch vehicle because of strength and durability
issues, more pulleys will be added to the frame to help distribute the force of tension. The cable
would then be intertwined between the pulleys, thus making it easier for the RES to lift. the launch
vehicle.
5.7.3. RPDS Payload Insertion Test
The payload insertion test proves the strength capability of the robotic arm and its precision to
accomplish the task. The test is simple and direct. A payload is placed approximately a foot away
from the robotic arm. The arm then approaches the payload, grabs it with the claw, moves it above
the locking component and finally presses it into the lock. This test can be formed in two different
ways. Either through predetermined movements by the servo motors, or through constant feedback
from ultrasonic sensor readings. If the option of the usage of sensors is optimized through trials
and better programming algorithms, it shall be the adequate method for the robotic arm movement.
The ultrasonic sensor will only be used to locate the payload and the locking component.](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-74-320.jpg)
![2015-2016 Georgia Tech Team ARES
Critical Design Review
Page 87 of 92
Appendix I: Scheduler
#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>
/*
* Time between running blocks of code. Not based on time but rather how much
* each block will run relative to the others. For example, the sensors will be
* polled once for every 5 times the state estimator runs.
*/
static uint16_t POLL_SENSOR_RATE = 5;
static uint16_t STATE_ESTIMATE_RATE = 1;
static uint16_t CONROLLER_RATE = 100;
/*
* Variables for holding sensor values, and flags if they have been updated
* (Once they are used by the state estimator, they will be set back to false)
*/
float altitude_sensor;
float acceleration_sensor[3];
bool altitude_updated;
bool acceleration_updated;
/* Estimations of position, velocity, and acceleration */
float position_est[3]; /* added '_est' to show this is an estimation */
float velocity_est[3];
float acceleration_est[3];
/* True if pins are currently deployed, false otherwise */
bool control;
/*
* Count how many times loop has run. Use to determine when to call different
* blocks. unsigned so an overflow won't cause it to go negative.
*/
uint16_t schedule_counter = 0;
/* Function prototypes. Will go in the header file with details */
int scheduler();
int poll_sensors(float *altitude, float *acceleration,](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-88-320.jpg)
![A CREDIBLE AUTOCODING APPLICATION WITHIN A ROCKET AND ITS
PAYLOAD
Raphael Cohen, Anh-Toan Bui long, Romain Jobredeaux and Eric Feron
Georgia Institute of Technology, Atlanta, Georgia
Abstract
The cost of software engineering and avionics
represents more than half of the budget of a safety-
critical system like an aircraft or a UAV. The quantity
and the complexity of embedded software in such
systems is increasing exponentially. Reducing their
cost of development is a major objective in the
aeronautics and avionics industry. Research in Cyber
Physical Systems (CPS) endeavours to contribute to
this objective. The traditionnal approach to certify-
ing software is to design unit tests to match low
level requirements, and integration tests to validate
high level requirements. Creating and running these
tests require large amounts of time and money. With
the recent bloom of companies specialized in UAV
and small systems design, there is a need for new
methods able to generate reliable codes in large
projects easily, quickly, and in a cost efficient manner.
Formal methods are a collection of techniques for the
mathematical analysis of programs and models, which
can assist in the certification of software with respect
to FAA and EASA certification guidelines.
New approaches to software verification, using
formal methods, have been developed in the past few
years. In this article, we will focus on a particular
method of code generation called the Credible Au-
tocoding [1]. Credible Autocoding is a method of
certification rooted in model-based design principles
and credible compilation. In particular, the tool de-
scribed in [2] accepts as an input a Simulink model of
a system and then translates it into annotated C code.
Simulink is widely used by control engineers, and this
technique enables the design to occur at this high
level of description, while guarantees are given on
the C implementation. C code is generated containing
a mathematical proof of desirable properties of the
system in annotations. The annotations, included in
the C code as comments, describe the behavior of the
system in a formal language. Using proper formal
analysis tools, the validity of these comments can be
assessed [3].
We demonstrate an experimental implementation
of this technique on a system. We will present an
application on a rocket system and its payload. We
used Credible Autocoding for the control command
of the rocket, and for filtering the data coming from
different sensors including the rocket system and
the payload. This research was carried out through
a competition organized by NASA, which requires
students to build a whole rocket with constraints
on several features and performance. The advantage
of Credible Autocoding here is the fact that this
technique is a great model-based (Simulink) approach
that uses formal method to generate documented code
and verifies it.
We first introduce the different approaches used
to generate certifiable code, and make a case for the
Credible Autocoding framework in Section 1. Then,
in Section 2, we present the project, objectives and
restrictions under which this research was carried out.
In Section 3, we discuss the work done on the payload
carried by the rocket. Sections 4 and 5 introduce the
rocket equation, the chosen control strategy and its
stability analysis at model level. Finally, Section 6,
the main contribution of this paper, describes how
to annotate the implementation of a sliding mode
controller with its stability proof. We discuss how to
extend the credible autocoding tool to support this
more sophisticated control strategy.
A Case for Credible Autocoding
Typical model-based design approaches to the
development of safety- critical systems rely on a level
A (according to DO 178B classification) certified
autocoder. Such autocoders have been developed fol-
lowing rigorous software engineering practices, which
involve careful documentation of every functionality
of the program, as well as a considerable amount
of tests and simulation to ensure, as much as tests](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-98-320.jpg)
![and simulation can, that the autocoder is free of any
damageable bug, and that it behaves according to
its specification. Based on this absolute trust in the
certified autocoder, it is argued that there is no need
to spend too much effort on the verification of the
generated code, as long as the input model to the
autocoder has been thoroughly verified and validated.
The Credible Autocoding approach, on the other
hand, emphasizes the verifiability of the generated
code, rather than that of the autocoder itself. Indeed,
using a minimal amount of proof information given at
the design level from a domain expert, Credible Au-
tocoding proposes to automatically generate not only
the code implementing a design, but also a formal
documentation describing its semantics. The code,
along with the documentation, can then easily be
verified using formal analysis tools, as demonstrated
in [2]–[4]. The value of this alternative approach
is two-fold: first, it seems important that the actual
code, to be embedded on the safety-critical system,
be subjected to the highest level of scrutiny, rather
than the tool that led to its generation. No verifi-
cation or validation process is perfect, but one can
reasonably expect to obtain higher levels of assurance
from taking the analysis as close to the final product
as possible. In addition, blind trust in an autocoder
may be misplaced, as demonstrated by the following
example.
GeneAuto [5]–[7] is an open source autocoder
developed with the objective of producing embedded
code for safety-critical applications. It takes as input
a model in Simulink, and can generate code in C
or ADA that implements the model. In [2], [4],
GeneAuto was extended with automatic generation
of formal annotations, in what constituted the first
demonstration of feasibility of the Credible Autocod-
ing framework. A verification backend was developed
to formally verify the annotated code generated by the
extended tool [3]. In the process, a bug was discov-
ered in the autocoder that had remained undetected
for many years. Without entering into its details, the
bug was triggered when using a gain block with a
matrix gain containing negative entries: the negative
sign would be lost in the translation. The authors were
alerted to this bug when the translation of a design
with a well understood proof of stability was failing
the verification of its documentation. Using the line-
by-line annotations, the authors were able to pinpoint
the origin of this failure, and subsequently identify
the bug.
More exhaustive testing might have exposed this
flaw, but it has been established that testing shows
the presence, not the absence of bugs [8]. The formal
analysis carried out following the Credible Autocod-
ing framework, when it succeeds, proves that the
implementation of a design is valid. It can succeed
in spite of the autocoder having bugs. While such an
outcome is undesirable, it is still acceptable from a
verification perspective, since the generated code, and
not the autocoder, is a part of the final product. There
can be many reasons why the verification backend
fails, but being able to pinpoint the location of the
failure allows to more efficiently trace the issue back
to where it originated.
More recent certification documents, like the DO
178C [9] and its addendum (DO 333 [10]), advocate
for the use of formal methods in the safety-critical
software development process. A formally certified
autocoder, along the lines of the one in [11], but at
a higher level of translation, would make the first
approach significantly more trustworthy, but does not
exist, to the authors’ knowledge.
The Project
The aim of the project is to embed a payload
within a rocket. The whole system is built by students.
The payload is meant to retrieve atmospheric data. In
order to retrieve it after the launch, it is hooked to a
parafoil which can be oriented at a predefined GPS
position. The rocket is part of a competition orga-
nized by NASA. It should reach an apogee of 3000
feet above ground level. To achieve this objective,
a system of spoilers called ATS (Apogee Targeting
System) is used. Less than 50 milliseconds after the
apogee, the parachute of the rocket should deploy
in order to deliver the payload at apogee. The flight
command and the apogee targeting system are coded
with the help of C code.
A Sensor Canister
The payload has several objectives:
• retrieve atmospheric datapoints at different alti-
tudes of the drop
• filter these values for further data treatment
• reach a target point using only a parachute that
can be controlled with its brakes](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-99-320.jpg)
![Rocket Equations and Control
In this section we discuss the first step of the
rocket study, which consists of deriving the equation
and implementing a controller that stabilizes a desired
trajectory. The rocket built is part of the project
described in section 2, which mission goal includes
launching the rocket while carrying a payload and
make it reach exactly 3,000 ft at apogee.
Equation of the Rocket
As a first step, let us derive the equation of the
rocket. Let W and D denote the weight and drag of
the rocket. Let Ve be the exhaust gas velocity. Then:
W+D =
d
dt
(mV) = ma+ ˙mVe. (5)
We assume that the direction of the rocket is
constant. As a consequence, the angle between the
axis pointing towards the nose of the rocket and the
vertical axis is constant and equal to a = 5 deg. Then,
projecting the previous equation along the vertical
axis yields:
m¨h = [ ˙mVe D]cos(a) mg, (6)
where h is the altitude and Ve the magnitude of Ve.
In order to control the altitude of the rocket, we used
a system of pins controlled by a motor. The motor
can control how much the pins are extended and,
therefore, how much drag they create. The total drag
force can be written as:
D =
1
2
rV2
(CrocketSr +CpinSp),
where Crocket and Cpin are the drag coefficients
of the rocket’s body and pins, and Sr and Sp the
associated surfaces. Introducing the vertical thrust,
Tv = ˙mVe cos(a):
¨h =
Tv
m
g
cos(a)
2m
rV2
(CrocketSr +CpinSp),
where
V2
= (
˙h
cos(a)
)2
=
˙h2
cos(a)2
,
Sp = Spo u.
Spo corresponds to the exact amount of pin
surface needed to reach an altitude of 3000 ft. The
nominal trajectory hp is obtained by setting u = 0,
and would yield the desired behavior in the absence
of disturbance: (i.e., Sp = Spo):
¨hp =
Tv
m
g
CrocketSrr
2m
˙hp
2
cos(a)
r
2m
˙hp
2
cos(a)
CpinSpo.
Therefore, defining the state variables x1 and x2 as
the vertical position and velocity discrepancy to hp,
x1 = Dh = h hp,
x2 = ˙Dh = ˙h ˙hp,
we obtain the following dynamics:
(
˙x1 = x2,
˙x2 = f(x,t)+g(x,t)u,
(7)
where
f(x,t) =
(CrocketSr +CpinSpo)r
2mcos(a)
(2 ˙hpx2 +x2
2
), (8)
g(x,t) =
rCpin
2mcos(a)
( ˙hp +x2)2
. (9)
Control of the Rocket
In order to control the system, we chose to imple-
ment a Sliding Mode Controller. Following standard
practice [12], we define a sliding surface s as:
s(x) = lx1 +x2 =
⇥
l 1
⇤
x.
On the surface defined by {x 2 R2|s(x) = 0}, x2 =
˙x1 = lx1, which induces a desired exponential con-
vergence of x1 to 0. Parameter l is chosen at design
time based on the required speed of convergence.
Thus, in order to find a control law that stabilizes
the origin we wish to validate the following candidate
Lyapunov function:
V(x) =
1
2
s2
=
1
2
(lx1 +x2)2
.
Its time derivative is given by
˙V(x,t) = s˙s = s(lx2 + ˙x2) = s(lx2 + f(x,t)+g(x,t)u).
We choose the following control law:
u = ueq +uc,
where 8
>><
>>:
ueq =
1
g(x,t)
(lx2 + f(x,t)),
uc =
1
g(x,t)
(Ksgn(s)).](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-102-320.jpg)
![The function sgn is the traditional sign function. Pa-
rameter K is chosen at design time and characterizes
the speed of convergence to the set {x 2 R2|s(x) = 0}.
Then:
˙V(x,t) = Ks·sgn(s).
As s·sgn(s) is always nonnegative, we thus have:
˙V(x,t) = Ks·sgn(s) 0. (10)
Stability Analysis of the System
In this section, we focus on the stability analysis
of the discretized system. Indeed, the implementation
of the control law will be a zero-order hold version
of the continuous controller described in Section 4.
In order to make a proof of stability on the system
tractable, we discretize its model and carry out a
discrete stability analysis.
Discretized Model
The system is discretized with a sample time of
Dt = 0.02 s. A first order Euler discretization yields
the following model.
xk+1 = xk +Dt
x2,k
fk +gkuk
. (11)
The state variables, sliding surface and functions
become:
xk = x(kDt) ; fk = f(xk,kDt) ; gk = g(xk,kDt)
Vk =
1
2
s2
k ; sk =
⇥
l 1
⇤
xk
A Matlab implementation of the controller is given
in Figure 4. Our goal is to express an invariant set
on the state variables of the rocket, in order to prove
Lyapunov stability of the closed loop system. Indeed,
equation (10) does not carry over directly in discrete
time. The controller accepts as inputs the state x,
computes the values of functions f and g and outputs
the target area of the pins u.
We begin the analysis by searching for a bound
on the sliding surface s.
⌥ ⌅
1 lambda = 0 . 1 ;
2 K = 0 . 5 ;
3 deltat = 0 . 0 2 ;
4 time = 0;
5 x = xo ;
6 s = [lambda 1]⇤x ;
7 while 1
8 x = receive(x , 1 ) ;
9 s = [lambda 1]⇤x ;
10 f = receive(f , time , 2 ) ;
11 g = receive(g , time , 3 ) ;
12 Ueff = 1/g⇤(K⇤ sign (s) ) ;
13 Ueq = 1/g⇤(lambda⇤x2+f) ;
14 U = Ueff + Ueq ;
15 send(U , 1 ) ;
16 time = time + deltat ;
17 end
⌃ ⇧
Figure 4. Matlab Code of the Controller
Sliding Surface Stability Analysis
In order to find a bound on s, we study the
variation of the function V. We show that it is non-
increasing. First, expressing sk+1 as a function of sk:
sk+1 =
⇥
l 1
⇤
xk+1,
sk+1 = sk +Dt
⇥
l 1
⇤
x2,k
fk +gkuk
.
Then, recalling that
uk =
1
gk
(K.sgn(sk)+ fk +lx2,k),
yields:
sk+1 = sk KDt sgn(sk). (12)
Equation (12) enables us to conclude that, in terms
of V:
Vk+1 Vk =
1
2
(s2
k+1 s2
k)
=
KDt
2
(KDt 2|sk|) (13)
We can see that the sliding surface s is decreasing in
norm whenever its norm is greater or equal than KDt
2 =
0.025. Initially, |x1,0| 2 and |x2,0| 1, so |s0| 1.2.
We now prove that Is = {|s| c} with c = 1.2 is
an inductive invariant set for s. For that, let us assume
that |sk| c. Then, two options are possible.
• Either |sk| KDt
2 . In that case, the function V
(and the norm of s) is non-increasing and thus:
|sk+1| c.](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-103-320.jpg)
![• Or |sk| KDt
2 . Then, using equation (12),
|sk+1|
KDt
2
+KDt =
3KDt
2
c.
In conclusion, the set Is = {|s| c} is indeed an
invariant set for the system.
An Inductive Invariant for the State Space
Using the invariant set for s, we now look for
an invariant set for x1 or x2. Indeed, s being a linear
combination of x1 and x2, we only need to find a
bound on x1 or x2, having already a bound on s. We
chose here to find a bound on x1. For that, we will
first compute x1,k+1 as a function of x1,k and sk.
x1,k+1 = x1,k +Dtx2,k = x1,k +Dt(sk lx1,k),
= x1,k(1 lDt)+Dtsk.
Now, let us assume that |sk| c and |x1,k| c
l . Then,
|x1,k+1| (1 lDt)
c
l
+cDt =
c
l
.
Thus, the set I = {|s| c,|x1| c
l } is an invariant
set for the system. Figure 5 depicts I in the (x1,x2)
plane.
Figure 5. Invariant Set Schema of System in Terms
of x1 and s
Generalisation to n-th Order Systems
In the prospect of applying credible autocod-
ing to generic sliding-mode control strategies, it is
important to explore potential generalizations of the
proposed approach to state-spaces of any dimension.
Indeed, this study could be applied to any system of
the form:
xk+1 = xk +Dt
2
6
6
4
x2,k
x3,k
...
fk +gkuk
3
7
7
5,xk =
2
6
6
4
x1,k
x2,k
...
xn,k
3
7
7
5. (14)
In that case, the sliding surface is typically defined
as:
sk =
✓
d
dt
+l
◆n
xk (15)
which is also, using the binomial formula:
sk = Kxk =
⇥
k1 k2 ... kn
⇤
xk,ki =
✓
n 1
i 1
◆
li 1
.
(16)
The surface defined by s = 0, exactly like in di-
mension two, has the properties to make the system
converge to the origin as a decreasing exponential
function. Then, knowing that the system admits a
bound on s and converges to the origin on the sliding
surface, a similar approach can yield an inductive
invariant for the system.
Introducing Sliding Mode Semantics in
Simulink Diagrams and at the Level of
the Code
In this section we will discuss how to incorpo-
rate the proof of stability and the semantics of the
functions f and g into the Simulink model. We will
also discuss how to express these semantics at the
level of the C code and the general necessity for a
library of certified functions for the computation of
non-linearities such as the ones involved in the model
description. Note that, to our knowledge, this is the
first attempt at formal verification of a sliding mode
controller.
The Verification Process
In order to produce a verified code, we proceed
in two steps. The first one involves adding all the
semantics related to the controller within annotation
blocks in the Simulink model of the controller, as
presented in [13] and [2], and then generating the C
Code containing the proof of stability. The second
task consists in writing a C code library containing
all the basic functions needed in the calculation of f
and g. The added value of this C code library lies in
that the functions written in this library are annotated
with ACSL contract and the library as a whole can
be proven correct using an automated prover. This
certified library, combined with the inserted invariant
in the annotated C code corresponding to the con-
troller, provide clear mathematical evidence of the
closed loop stability of the embedded system.](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-104-320.jpg)
![Figure 6. Global Diagram of the Verification Pro-
cess
Figure 6 presents a global description of the
design, analysis and verification process. As indicated
in this figure, the certified C Code library is written
manually at this point. The objective, however, is to
eventually provide a more complete library of non-
linear functions so that the verification process for
this type of control law can be automatically done
for a larger set of f and g functions.
Expressing Semantics with Custom Annotation
Blocks in Simulink
In order to have the complete semantics of the
controller, we need to analyze the functions f and
g. The Matlab code of the controller along with the
annotations expressing the system stability are given
in Figure 8. From the analysis of the function f, we
were able to see that the norm of f is less than or
equal to 0.2688. For the function g, a bound on a
norm will not be useful. The issue with g arises when
it approaches zero. As such, we need to ensure that it
remains non-zero throughout the execution of the pro-
gram. For that reason, we chose to start the controller
at t0 = 0.06. Starting the execution of the controller
at t0 = 0.06 and having |x1,0| 2, |x2,0| 1 we can
then prove that g 0.008. As a consequence we can
conclude on a bound for Ueq, Uef f and U. For now,
the Credible Autocoding technique described in [2],
[13] is only capable of propagating into the C code,
Ellipsoid invariants (being very useful for Linear
Systems) thanks to Simulink annotation blocks. Here,
we need to make sure that the g function will never
be equal to zero, which is a different kind of invariant
property. On top of that, we also has to change the
way to call f and g. In fact, the C code program of
the controller has to call the routines get_f and get_g
written in the certified library. As a consequence, we
need then to create some others simulink annotation
blocks in order to generate a annotated C Code similar
to the Matlab code presented in figure 8.
Figure 7. Annotation Blocks Allowing to Enter F
and G Functions Semantics
Figure 7 suggests new annotation blocks to de-
fine the semantics of non-linear systems in the form
of equation (14).
⌥ ⌅
1 lambda = 0 . 1 ;
2 K = 0 . 1 ;
3 deltat = 0 . 0 2 ;
4 time = 0 . 0 6 ;
5 x = xo ;
% |x1| 2 && |x2| 1
6 s = [lambda 1]⇤x ;
% |s| 1.2 && |x1| 12
while 1
% |s| 1.2 && |x1| 12
7 x = receive(x , 1 ) ;
% |s| 1.2 && |x1| 12
8 f = get_f(x , time) ;
% | f| 0.2689
9 g = get_g(x , time) ;
% g 0.008
10 Ueff = 1/g⇤(K⇤ sign (s) ) ;
% |Uef f| 62.5
11 Ueq = 1/g⇤(lambda⇤x2+f) ;
% |Ueq| 63.62
12 U = Ueff + Ueq ;
% |U| 126.12
13 send(U , 1 ) ; time = time + deltat ; end
%{ f a l s e }
⌃ ⇧
Figure 8. Matlab Implementation of the Controller
Containing All the Annotation
Verification by Software Prover
In order to check that all the proof annotations
are correct, we will use a software prover called
Frama-C. A C code library of basic functions called](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-105-320.jpg)
![by get_g and get_f with ACSL annotations has
been manually written. Is is presented in Figures 9
and 10. Indeed, in order to be able to verify that
the outputs from the f and g functions are truly in
the sets specified in section 1, we need some more
information about these functions. The purpose of the
C Code Library is primarily to provide the control
program with the required functions, but also to allow
a software prover such as Frama-C to verify their im-
plementation. As shown in the figure 6, the software
prover will then be able to check the correcteness of
the whole system composed of the C code controller
generated by the autocoder and the C code library.
⌥ ⌅
# i n c l u d e < s t d i o . h>
# i n c l u d e <math . h>
/⇤@lemma div : f o r a l l double x , double y ;
x >= 0 ==> y > 0 ==> x / y > 0; ⇤/
i n t h_p[709] , v_p [ 7 0 9 ] ; double lambda , K ;
/⇤@ a s s i g n s nothing ;
@ behavior behav1 :
@ assumes a > 0 && b >0;
@ ensures r e s u l t >0;
@ behavior behav2 :
@ assumes 0.92 <= a <= 1.0008;
@ assumes 5.25 <= b <= 5 . 2 6 ;
@ ensures 0.644946 <= r e s u l t <=1.004216;
@ behavior behav3 :
@ assumes 0.6 <= a ;
@ assumes b ==2;
@ ensures 0.36 <= r e s u l t ;
@ behavior behav4 :
@ assumes 2.4 <= a <= 2 . 4 ;
@ assumes b ==2;
@ ensures 0 <= r e s u l t <= 5 . 7 6 ;
@⇤/
double pow( double a , double b) ;
/⇤@ r e q u i r e s 15 <= h <= 1500;
@ ensures 0.758 <= r e s u l t <= 1.189481 ;
@ a s s i g n s nothing ;
@⇤/
double get_rho( double h) ;
⌃ ⇧
Figure 9. ACSL Annotated Header File of the C
Code Library (Part 1)
Conclusion
We presented an approach to extending the cred-
ible autocoding framework to a wider category of
⌥ ⌅
/⇤@ r e q u i r e s t >= 0;
@ ensures 7.07 <= r e s u l t <= 7 . 6 6 ;
@ a s s i g n s nothing ;
@⇤/
double get_mass( double t) ;
/⇤@ r e q u i r e s t >= 0;
@ ensures 0 <= r e s u l t <= 914;
@ a s s i g n s nothing ;
@⇤/
double get_hp( double t) ;
/⇤@ r e q u i r e s t >= 0 . 0 6 ;
@ ensures 3 <= r e s u l t <= 143;
@ a s s i g n s nothing ;
@⇤/
double get_vp( double t) ;
/⇤@ r e q u i r e s 0.06 <= t && 12 <= x1 <= 12;
@ r e q u i r e s 1.2 <= s <= 1 . 2 ;
@ ensures r e s u l t > 0 . 0 0 8 ;
@ a s s i g n s nothing ;
@⇤/
double get_g( double t , double x1 , double s) ;
/⇤@ r e q u i r e s 0.06 <= t && 12 <= x1 <= 12;
@ r e q u i r e s 1.2 <= s <= 1 . 2 ;
@ ensures 0.2689 <= r e s u l t <= 0.2689;
@ a s s i g n s nothing ;
@⇤/
double get_f( double t , double x1 , double s) ;
⌃ ⇧
Figure 10. ACSL Annotated Header File of the C
Code Library (Part 2)
control systems, and its application to the problem
of controlling the altitude of a rocket. We described
how to look for invariant sets for sliding mode control
law with proof, and then how to carry it down to
the generated code. So far, the study that has been
done was very theoretical. Indeed, the annotations
translating the invariant sets were added manually to
the code and the C code library was as well manually
written and proved by Frama-C. However, this first
step paves the way for automation, as the work in [1]
paved the way for the automated tool presented in [2].
One future work will be to complete the automated
process of propagating invariant sets along the gen-
erated C code. The user is only capable of enter
sliding mode control semantics into the Simukink
model via annotation blocks but these blocks do
not generate any annotations so far. This work will
involve extending an existing plugin in the GeneAuto](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-106-320.jpg)
![tool. Other worthwhile avenues of research include
carrying down properties of robustness: indeed one
useful property of sliding mode controller is their
ability to absorb model errors within functions f and
g by tuning parameters l and K. Quantifying this
property at the level of the code would be particu-
larly useful. In addition, the time-varying nature of
this system makes it very sensitive to delays, and
this sensitivity would deserve some further study.
Finally, the annotations provided in this paper assume
computations yield their exact real result, whereas
floating-point computation effects should be taken
into account for a fully sound analysis.
References
[1] E. Feron, “From Control Systems to Control Soft-
ware,” Control Systems, IEEE, vol. 30, no. 6, pp. 50
[2] T. Wang, R. Jobredeaux, H. Herencia-Zapana, P.-
L. Garoche, A. Dieumegard, E. Feron, and M. Pantel,
“From Design to Implementation: an Automated,
Credible Autocoding Chain for Control Systems,”
CoRR, vol. abs/1307.2641, 2013. [Online]. Available:
http://arxiv.org/abs/1307.2641.
[3] R. Jobredeaux, “Formal Verification of Control
Software,” PhD thesis, Georgia Institute of Technol-
ogy, 2015.
[4] T. E. Wang, “Credible Autocoding of Control
Software,” PhD thesis, Georgia Institute of Technol-
ogy, 2015.
[5] N. Izerrouken, X. Thirioux, M. Pantel, and M.
Strecker, “Certifying an Automated Code Generator
Using Formal Tools : Preliminary Experiments in
the GeneAuto Project,” in ERTS, http://www.sia.fr:
Société des Ingénieurs de l’Automobile, 2008, (elec-
tronic medium).
[6] A. Toom, N. Izerrouken, T. Naks, M. Pantel, and
O. Ssi-Yan-Kai, “Towards Reliable Code Generation
with an Open Tool: Evolutions of the Gene-Auto
Toolset,” in ERTS, http://www.sia.fr: Société des In-
génieurs de l’Automobile, 2010, (electronic medium).
[7] A. Toom, T. Naks, M. Pantel, M. Gandriau, and
I. Wati, “Gene-Auto - an Automatic Code Generator
for a Safe Subset of Simulink-Stateflow and Scicos,”
in ERTS, http://www.sia.fr: Société des Ingénieurs de
l’Automobile, 2008, (electronic medium).
–71, 2010, ISSN: 1066-033X. DOI: 10.1109/MCS.
2010.938196.
[8] J. Buxton and B. Randell, “Software Engineering
Techniques,” in Report on a conference sponsored
by the NATO Science Committee, 1969. [Online].
Available: http : / / homepages . cs . ncl . ac . uk / brian .
randell/NATO/nato1969.PDF.
[9] S. C. RTCA, “DO-178C, Software Considerations
in Airborne Systems and Equipment Certification,”
Special Committee 205 of RTCA, Tech. Rep., 2011.
[10] ——, “DO-333 Formal Methods Supplement to
DO-178C and DO-278A,” Tech. Rep., Dec. 2011.
[11] X. Leroy, “Formal Verification of a Realistic
Compiler,” Communications of the ACM, vol. 52, no.
7, pp. 107–115, 2009. [Online]. Available: http : / /
gallium.inria.fr/~xleroy/publi/compcert-CACM.pdf.
[12] H. Khalil, “Nonlinear Systems,” Prentice Hall,
2003.
[13] R. Jobredeaux, T. Wang, and E. Feron, “Au-
tocoding Control Software with Proofs I: Annotation
Translation,” Digital Avionics Systems Conference
(DASC), vol. 10.1109/DASC.2011.6096122, pp. 7C1–
1 –7C1–13, 2011.
Acknowledgments
This article was prepared thanks to the support
of the National Science Foundation under grant
1446758 (SORTIES) and the Army Research
Office under MURI award W911NF-11-1-0046.
Additionally, we would like to thank the National
Aeronautics and Space Administration (NASA)
for organizing such project and competition within
American universities.
The authors would also like to thank Arnaud
Dieumegard for his help on the GeneAuto.
34th Digital Avionics Systems Conference
September 13–17, 2015](https://image.slidesharecdn.com/cdrares-170221234209/85/Critical-Design-Review-Paper-for-Project-A-R-E-S-107-320.jpg)
Critical Design Review Paper for Project A.R.E.S.
- 1. Georgia Institute of Technology Team ARES 120 North Ave NW Atlanta GA 30332 Project Hermes January 15, 2016
- 2. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 1 of 92 Table of Contents 1. INTRODUCTION...............................................................................................................................4 1.1. TEAM SUMMARY ..........................................................................................................................4 1.2. WORK BREAKDOWN STRUCTURE .................................................................................................4 1.3. LAUNCH VEHICLE SUMMARY ......................................................................................................5 1.4. AGSE SUMMARY .........................................................................................................................5 2. CHANGES MADE SINCE PDR .......................................................................................................7 2.1. LAUNCH VEHICLE CHANGES........................................................................................................7 2.2. AGSE CHANGES...........................................................................................................................7 2.3. PROJECT PLAN CHANGES .............................................................................................................7 3. LAUNCH VEHICLE CRITERIA.....................................................................................................8 3.1. DESIGN AND VERIFICATION OF LAUNCH VEHICLE ......................................................................8 3.1.1. Mission Statement................................................................................................................8 3.1.2. Mission Success Criteria .....................................................................................................8 3.1.3. Major Milestone Schedule ...................................................................................................9 3.2. SYSTEM DESIGN REVIEW ...........................................................................................................10 3.2.1. Final Motor Selection........................................................................................................13 3.3. SYSTEM LEVEL FUNCTIONAL REQUIREMENTS ..........................................................................14 3.4. MANUFACTURING APPROACH....................................................................................................15 3.4.1. Payload Section .................................................................................................................15 3.4.2. Avionics Section.................................................................................................................18 3.4.3. Booster Section ..................................................................................................................20 3.4.4. Status and Plans of Remaining Manufacturing and Assembly..........................................22 3.4.5. Integrity of Design .............................................................................................................22 3.5. SUBSCALE FLIGHT RESULTS.......................................................................................................26 3.5.1. Flight Data.........................................................................................................................26 3.5.2. Result Discussion...............................................................................................................27 3.5.3. Impact on Full Scale..........................................................................................................28 3.6. RECOVERY SUBSYSTEM .............................................................................................................30 3.6.1. Recovery System Hardware...............................................................................................30 3.6.2. Electrical Hardware ..........................................................................................................30 3.6.3. Kinetic Energy Calculations..............................................................................................31 3.7. MISSION PERFORMANCE PREDICTIONS ......................................................................................32
- 3. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 2 of 92 3.7.1. Validity of Analysis............................................................................................................32 3.7.2. Drag Assessment................................................................................................................33 3.8. FUTURE TESTING ........................................................................................................................34 3.9. LAUNCH PROCEDURES ...............................................................................................................35 3.9.1. Launch Checklist ...............................................................................................................35 3.10. SAFETY AND ENVIRONMENT..................................................................................................39 3.10.1. Overview............................................................................................................................39 3.10.2. Failure Modes and Analysis ..............................................................................................40 3.10.3. Personnel Hazards.............................................................................................................44 3.10.4. Environmental Concerns ...................................................................................................44 4. FLIGHT SYSTEMS..........................................................................................................................46 4.1. OVERVIEW ..................................................................................................................................46 4.2. SIMULINK DESIGN OVERVIEW....................................................................................................48 4.3. CONTROLLER DESIGN OVERVIEW..............................................................................................50 4.3.1. Control Technique .............................................................................................................50 4.3.2. Sliding Mode Control ........................................................................................................51 5. AGSE CRITERIA.............................................................................................................................53 5.1. AGSE SUMMARY .......................................................................................................................53 5.2. DESIGN REVIEW OF AGSE EQUIPMENT .....................................................................................54 5.2.1. Robotic Payload Delivery System (RPDS) ........................................................................54 5.2.2. Rocket Erector System (RES).............................................................................................57 5.2.3. MIS.....................................................................................................................................59 5.2.4. Electronics .........................................................................................................................62 5.3. MISSION SUCCESS CRITERIA AND FUNCTIONAL REQUIREMENTS..............................................64 5.4. MANUFACTURING APPROACH....................................................................................................65 5.4.1. Overall Manufacturing Approach .....................................................................................65 5.4.2. RPDS..................................................................................................................................65 5.4.3. RES ....................................................................................................................................66 5.4.4. MIS.....................................................................................................................................66 5.4.5. Electronics .........................................................................................................................67 5.5. REMAINING MANUFACTURING AND ASSEMBLY........................................................................67 5.6. AGSE ELECTRONICS ..................................................................................................................68 5.6.1. AGSE Electronics Overview..............................................................................................68
- 4. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 3 of 92 5.6.2. Drawings and Schematics..................................................................................................69 5.6.3. Block Diagrams .................................................................................................................70 5.6.4. Batteries/Power .................................................................................................................71 5.6.5. Switch and indicator Wattage and Location .....................................................................71 5.7. COMPONENT TESTING ................................................................................................................72 5.7.1. Electronics Pause Button Test...........................................................................................72 5.7.2. RES Lifting Test .................................................................................................................73 5.7.3. RPDS Payload Insertion Test ............................................................................................73 5.8. INTEGRATION PLAN....................................................................................................................74 5.9. FAILURE AND SAFETY ANALYSIS...............................................................................................75 6. PROJECT PLAN ..............................................................................................................................77 6.1. BUDGET PLAN.............................................................................................................................77 6.2. FUNDING PLAN ...........................................................................................................................78 7. PROJECT SCHEDULE ...................................................................................................................80 7.1.1. Critical Path Chart: CDR to PLAR...................................................................................80 7.2. SCHEDULE RISK..........................................................................................................................83 8. EDUCATIONAL OUTREACH PLAN AND STATUS.................................................................85 8.1. OVERVIEW ..................................................................................................................................85 8.2. ATLANTA MAKER’S FAIRE.........................................................................................................85 8.3. FIRST LEGO LEAGUE ..................................................................................................................85 8.4. CEISMC GT...............................................................................................................................86 9. CONCLUSION..................................................................................................................................86 APPENDIX I: SCHEDULER ...................................................................................................................87 APPENDIX II: GANTT CHART.............................................................................................................90 APPENDIX III: TEST PLANS ................................................................................................................91 APPENDIX IV: CONTROL SYSTEM PAPER .....................................................................................92
- 5. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 4 of 92 1. Introduction 1.1. Team Summary Table 1: Team Summary Team Summary School Name Georgia Institute of Technology Mailing Address North Avenue NW, Atlanta GA 30332 Team Name Team Autonomous Rocket Equipment System (A.R.E.S.) Project Title Hermes Launch Vehicle Name Skyron Project Lead Victor R. Safety Officer Stephen K Team Advisors Dr. Eric Feron NAR Section Primary: Southern Area Launch vehiclery (SoAR) #571 NAR Contact, Number & Certification Level Primary Contact: Joseph Mattingly NAR/TRA Number: 92646 Certification Level: Level 2 Secondary: Jorge Blanco 1.2. Work breakdown structure Team Autonomous Rocket Erector System (ARES) is composed of twenty-one students studying varying fields of engineering. Our team is composed of less than 50% Foreign Nationals (FN) per NASA competition requirements. To work more effectively, the team is broken down into groups that focus on special tasks. Each sub-team has a general manager supported by several technical leads and subordinate members. Team memberships were selected based on each individual's area of expertise and personal interest. Error! Reference source not found. shows the work breakdown structure of Team ARES.
- 6. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 5 of 92 Figure 1: Team ARES Work Breakdown Structure 1.3. Launch Vehicle Summary The Skyron Launch Vehicle is 93.67 inches in length and projected to weigh 28.00 lb. with a 30% mass margin. Skyron is designed to accommodate a 3.5 inch PVC pipe payload in the payload bay located just before the nose cone. A Cesaroni Technology L990 reloadable rocket motor was chosen to propel the rocket to an apogee of 5280 ft. A 2.5 ft. diameter drogue parachute will deploy from a compartment between the booster and avionics sections an apogee, and a 4.3 ft. diameter main parachute will be deployed below 700 ft. AGL to slow the rocket such that the kinetic energy at ground impact will be below 75 ft.-lbf. 1.4. AGSE Summary Team ARES’ Autonomous Ground Support Equipment (AGSE) mission will be to secure the payload, raise the launch vehicle, and insert the igniter. The AGSE weighs a total of 60 lbs, has a 10 ft. by 4 ft. base, and a starting height of 1.5 ft. The Robotic Payload Delivery System (RPDS), using 4 servo motors, will deliver and secure the payload inside the payload bay of the launch
- 7. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 6 of 92 vehicle. The Rocket Erection System (RES), actuated by a bipolar stepper motor, will raise the launch vehicle from a horizontal position to a position 5 degrees from the vertical. The Motor Ignition System (MIS) will use a rack and pinion system powered by a unipolar stepper motor to insert the igniter. All the functions of the AGSE will be controlled by an Arduino Uno.
- 8. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 7 of 92 2. Changes Made Since PDR 2.1. Launch Vehicle Changes • 2.2. AGSE Changes • Made base wider for increased support • Added pulley to RES • Changed materials in MIS from plastic to steel • Decreased RPDS weight • Added more ball bearings MIS • Added electronics containment unit 2.3. Project Plan Changes • Updated deadlines to accurately reflect the status of the project • Update to the upcoming dates of launches and outreach efforts
- 9. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 8 of 92 3. Launch Vehicle Criteria 3.1. Design and Verification of Launch Vehicle 3.1.1. Mission Statement To maintain a sustainable team dedicated to the gaining of knowledge through the designing, building, and launching of reusable launch vehicles with innovative payloads in accordance with the NASA University Student Launch Initiative Guidelines. 3.1.2. Mission Success Criteria Table 2: Mission Success Criteria Requirement Design feature to satisfy that requirement Requirement Verification Success Criteria Reach an altitude of 5,280 ft. as accurately as possible. The A.T.S. will deploy during cruise flight to adjust the flight profile curve to match a real- time ideal projection of the rocket’s trajectory for the designated altitude by increasing the drag coefficient of the launch vehicle. Gathering data post- launch from the on- board altimeters. The A.T.S. directs the launch vehicle to an accuracy in apogee of 2%. The vehicle must be reusable. Robust materials will be selected for the components of the launch vehicle that will be subjected to high-stress environments. By inspecting every element of the launch vehicle to ensure no structure was compromised No visible structural damage is visible and every component is still functional The payload must be retained at all times during flight A payload bay with secure payload holders will provide sufficient force to prevent detachment due to vibrations. By inspecting the payload bay post- launch for partial or complete detachment. The payload will remain in the same position as it was pre- launch.
- 10. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 9 of 92 3.1.3. Major Milestone Schedule The following table represents the major milestones Project Hermes will encounter throughout the entirety of the competition. For a more detailed timeline please visit Appendix XX for a complete view of major deadlines, specific manufacturing dates, located in the 2015-2016 Gantt Chart. Table 3: Major Milestones Deadline Date Team Formation 20 AUG Proposal 11 SEPT Web Presence Established 23 OCT PDR Documentation 6 NOV PDR Teleconference 9-20 NOV CDR Documentation 15 JAN CDR Teleconference 19-29 JAN AGSE, Flight Systems, and Launch Vehicle Testing 29 JAN – 20 FEB Full Scale Testing and Launching 20 FEB FRR Documentation 14 MAR FRR Teleconference 17-30 MAR Competition 13-16 APR PLAR Documentation 29 APR
- 11. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 10 of 92 3.2. System Design Review The launch vehicle will be 93.67 inches long with a body tube diameter of 5.00 inches. The size of the rocket was chosen to allow spacing for the parachute bays, the main avionics bay, and the motor. OpenRocket simulation predicts that the Cesaroni L990 motor will result in an apogee of 5280 ft. with an extra mass of 615 grams to account for unexpected component additions. The launch vehicle is divided into three sections: the booster section, avionics section, and payload section. Table 4 lists materials used with motivation for material selections. Table 4: Material Selection Component(s) Material Motivation Body Tube/Nosecone G12 Fiberglass Resistance to high aerodynamic loads and ground impact Fins G10 Fiberglass Resistance to high aerodynamic loads and ground impact Bulkheads Plywood Cheap, lightweight, and reliable
- 12. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 11 of 92 The following Figures will provide a complete overview of Skyron’s separate components. Figure 2,3,4, & 5 represents a complete Solidworks model of the launch vehicle. Figure 2: Overview of Skyron Figure 3: Closeup of Fully Deployed ATS
- 13. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 12 of 92 Figure 4: Top View of a fully deployed ATS Figure 5: Top View of retracted ATS
- 14. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 13 of 92 Figure 6: Close up of Fin Section 3.2.1. Final Motor Selection The final motor choice for Skyron is a Cesaroni L990. We have selected this motor due to the increased space capacity it provides for the Apogee Targeting System within the Booster Section. Additionally, the L990 motor still has the necessary thrust to overshoot the target altitude of 5280 ft. so our ATS can be activated. The following Table XX outlines the specifications of the L990. Table 5: L990 Specifications MOTOR NAME Cesaroni L990 DIAMETER 54mm LENGTH 64.9cm PROP WEIGHT 1.369kg TOTAL WEIGHT 2.236kg AVG THRUST 991.0N MAX THRUST 1702.7N TOTAL IMPULSE 2771.6 BURN TIME 2.8s
- 15. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 14 of 92 3.3. System Level Functional Requirements Requirement Design Feature to Satisfy Requirement Verification Method Status Vehicle altimeter will report an apogee altitude of most nearly 5,280 feet AGL. Low-mounted electric-controlled fins will be extended and retracted in reaction to altimeter readings to control drag and limit altitude. Analysis In Progress Launch vehicle will be designed to be recoverable and reusable within the day of initial launch. Vehicle will be constructed of fiberglass to resist fractures and ensure stability. Design Review In Progress Vehicle will be prepared within 2 hours and will be able to maintain launch-ready position for at least 1 hour. Compartmentalized design with standard assembly procedure. Execution In Progress The launch vehicle shall have a maximum of four (4) independent sections. Three (3) sections include: payload, avionics, and booster Inspection In Progress The vehicle will be limited to a single stage, solid motor propulsion system, delivering an impulse of no more than 5,120 Newton-seconds. Single-staged design that utilizes a single “L” impulse classification motor. Design Review In Progress Team must launch and recover both a subscale and full scale model prior to each CDR and FRR respectively. Efficient Recovery System with redundancies to ensure successful operation. Execution In Progress The launch vehicle shall stage the deployment of its recovery devices, where a drogue parachute is deployed at apogee and a main parachute is deployed at a much lower altitude. Redundant altimeters programmed to deploy at specific altitudes. Inspection In Progress
- 16. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 15 of 92 At landing, the launch vehicle shall have a maximum kinetic energy of 75 ft-lbf. Optimization of parachute sizing for the total mass of the launch vehicle Testing In Progress The recovery system will contain redundant altimeters, each with their own power supply and dedicated arming switch located on the exterior of the rocket airframe Install a master key-switch at the rear of the avionics bay to close all circuits simultaneously, and independent compartment for sensors and power supply. Inspection In Progress Each detachable section of the vehicle and payload must contain an electronic tracking device and continue transmission to the ground throughout flight and landing. Independent GPS compartment with transmission capabilities and ground station with receiving capabilities. Inspection In Progress 3.4. Manufacturing Approach 3.4.1. Payload Section The payload bay will be a cutout into the airframe of Skyron which will have latch to secure the payload. In order to ensure maximum efficiency and achieve the precise dimensions for the incisions on the fiberglass airframe, a conventional CNC Mill was selected for this manufacturing process. This choice also guarantees the least amount of glass fibers delaminating from the epoxy composite, and under the correct safety procedures only produces fiberglass residues in the very manageable form of dust, minimizing the risk of toxic fume generation. This process will be utilized to manufacture the hatch for the payload bay which should maintain its structural integrity for its exposure to the high velocity flow during ascent.
- 17. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 16 of 92 In order to ensure maximum efficiency and achieve the precise dimensions for the incisions on the fiberglass airframe, a conventional CNC Mill was selected for this manufacturing process. This choice also guarantees the least amount of glass fibers delaminating from the epoxy composite, and under the correct safety procedures only produces fiberglass residues in the very manageable form of dust, minimizing the risk of toxic fume generation. This process will be utilized to manufacture the hatch for the payload bay which should maintain its structural integrity for its exposure to the high velocity flow during ascent. To house the payload bay in the upper section, two plywood bulkheads enclose the bay on either end.
- 18. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 17 of 92 The procedure for cutting plywood of various thicknesses involves using a high powered laser cutter. In order to create a component with exact dimensions, a two dimensional computer-aided design (CAD) file is drawn and then input through Inkscape into the high powered laser cutter. This procedure is fast and effective with an accuracy of a thousandth of an inch, allowing for near perfect assemblies when it comes to multiple components. For example, this method was utilized for the upper section to create the various thickness bulkheads as well as the support structure within the payload bay. This method guarantees that the manufacturing process can occur without any hazards to safety. Another method for manufacturing to be utilized for the upper section of the launch vehicle is additive manufacturing. This method provides a time effective method of transferring a three dimensional CAD file into solid structural material with the ability of having high reproducibility. The material with which the 3D printers operate is ABS plastic, which provides enough structural integrity and ease of handling to be used for more complex and delicate components of the design. It is for these reasons that additive manufacturing was utilized to create the payload holding clips that allow for slight deformation with full elastic recovery for the process of inserting and removing the payload. This material is also lightweight enough to be non-intrusive to the overall design of the launch vehicle so this method also allows for high margins for the modification of such components.
- 19. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 18 of 92 3.4.2. Avionics Section 3.4.2.1. Main Avionics Bay The avionics bay consists of two different materials: G12 fiberglass and 0.125in plywood boards. These two materials require different manufacturing methods to ensure that their structural integrity isn’t permanently affected. For the plywood boards, the conventional method for altering the dimensions of the board is using a high powered laser cutter for precise and safe manufacturing. As to the fiberglass tubes, what is most convenient is to use a table saw, while still taking into account the safety hazards that arise from cutting fiberglass, so the appropriate safety equipment must be used by every individual present during the time of manufacturing. As to the holes that secure the Avionics Bay in place, a conventional drill will be used while still accounting for the same safety hazards as previously discussed. These methods ensure there will be little deformation, delamination, and precise cuts for the manufacture of each component. The Avionics bay will house the components in charge with the recovery system, ATS system, and data collection system. Skyron’s Avionics Bay (AB) is where all the board readings, measurements and information is processed. To house all of the necessary avionics components
- 20. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 19 of 92 the AB will be placed on a 10” x 4.8” x 1⁄8” vertical plywood board which is a epoxied onto the smaller diameter of the inside of the avionics bay. The avionics bay itself consists of two symmetrical sections one of which is attached to the main body of the rocket and the other which can be easily inserted and removed via connection pins placed on the epoxied vertical board and metallic tabs extending from the edges of the inner diameter of the removable component. The key switch for the ignition will be placed on the avionics bay security latch which is screwed in with two standard ⅛” screws. The two security latches/doors are screwed in on both sides of the avionics bay with access to either side of the epoxied vertical board. Some major setbacks were found with the previous design in the subscale launch insertion, one of which was the difficulty of inserting the avionics “sled” in the avionics bay due to space congestion generated by the large number of wires and avionics equipment. This resulted in the “sled” not coinciding flush with the door cutout. Through the aforementioned new design, these insertion and setup difficulties are eliminated leading to ease of access, installation and reinforced security for the avionics components and bay in its entirety. 3.4.2.2. Nosecone GPS The GPS will be located within the nosecone of the launch vehicle to ensure that the signals do not interfere with the rest of the on-board electronics. To secure it in place, it will be mounted on a construction of ⅛” thickness plywood and with its base on the payload bay. The GPS will be mounted on one side of the plywood board while its isolated power supply is located on the other side of the board. This construction only requires a high powered laser cutter to manufacture the boards with the right dimensions and the right holes for the attachment points of the electronics. Attaching the GPS Bay to the rest of the launch vehicle will require it to be epoxied to the top of the bulkhead enclosing the payload bay, allowing it to be easily inserted into the nosecone before securing the latter in place with the assistance of screws.
- 21. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 20 of 92 3.4.3. Booster Section The Booster Section (BS) of Skyron will house the L990 Motor, and the Apogee Targeting System (ATS). For more information concerning the Motor selection please see Section XX. The Motor Retention Plate, which will hold the motor in place and prevent the motor from travelling straight through the Launch Vehicle, will be manufactured from ½ “ plywood. To ensure that the maximum thrust of the motor does not penetrate and create enough displacement to cause problems, we simulated the stress on the motor retention plate using Finite Element Analysis. Finite Element Analysis (FEA) is a numerical technique used for finding approximate solutions to partial differential equations. This technique is useful for theoretical analysis of design components. Solidworks utilizes this technique to perform basic FEA, and was used to analyze the thrust plate, shown below The force applied corresponds to the maximum thrust the Cesaroni L990 can produce, which is 382.62 lbf. The maximum displacement of the thrust plate was 0.01 inches with a maximum stress of 375 N/m^2. The figures were scaled to emphasize the displacement.
- 22. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 21 of 92 Another main component of the BS is the Apogee Targeting System (ATS). To assemble the ATS, four 3-D printed mounting frames will be evenly spaced around the booster. The frame consists of custom fit cut-outs for the ATS motor and battery to be placed inside. The bolt and lead screw will slide into the mounting frame and connected to the DC motor. The ATS tab will be attached to a hinge inside the body tube wall. The pivoting rods, which translate the bolts’ linear motion to the tabs, will have thin cut slots in the body tube to allow motion both inside and outside of the body tube. The ATS will be powered by four (4) DC motors. Each of the four ATS tabs will be connected to a lead screw powered by its own DC motor and battery incorporated within each separate mounting frame. The fins will be manufactured out of G10 Fiberglass sheets using a Maxiem 1515 CNC Waterjet. This method has proven to be successful in the past leading to an accurate cut with little to no safety concerns.
- 23. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 22 of 92 3.4.4. Status and Plans of Remaining Manufacturing and Assembly As of CDR, every major component is being assembled; the booster section, the avionics section, and the nosecone section. As more and more components arrive, more manufacturing will take place. The structural integrity of every part is being considered as we move toward the full scale testing. 3.4.5. Integrity of Design 3.4.5.1. Suitability of Shape and Fin Style The fins will be made using G10 Fiberglass as the material of choice. Initially, the fins were attempted to be made with a smooth airfoil shape in order to improve the aerodynamics of the fin and reduce drag. Due to complications in the sanding process, it was determined that the smooth airfoil shape would be unreasonable for the fins due to the fact that G10 Fiberglass is not one solid material, but multiple layers on top of each other. During sanding, it is expected that the layers would begin to peel off one another.
- 24. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 23 of 92 The fin has a clipped delta fin shape (as shown below) which was determined as the most viable option for a launch vehicle with four fins. With four fins, the stability of Skyron will increase as opposed to using only three fins (stability is expected increase by slightly over 50%). The fin flutter speed was calculated using the Flutter Boundary Equation published in NACA Technical Paper 4197: The corresponding variables for our fin are listed in Table 12 located below. The fin flutter speed was calculated to be 1326.109 mph. Comparing Vf to our maximum velocity Vmax of 552.148 mph (0.72 Mach), Skyron will not experience the unstable effects of fin flutter. Exceeding the fin flutter speed will exponentially amplify the oscillations and rapidly increase the energy in the fins; causing greater induced moments and more instability. Table XX: Fin Dimensions Variable Unit Speed of Sound, a 1105.26 ft/s Pressure, P 13.19 lbm/in2 Temperature, T 48.32 Fahrenheit Shear Modulus, G 425,000 psi Taper Ratio, 0.3627 Tip Chord 7 cm or 2.75591 in Root Chord 19.3 cm or 7.598 in Thickness 0.318 cm or 0.1252 in Fin Area 55.23 in2 Span 13.4 cm or 5.275591 in Aspect Ratio 0.50392
- 25. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 24 of 92 3.4.5.2. Material Analysis The fins of the rocket are going to be made of G10 fiberglass. This fiberglass is being used for its high ultimate breaking point and its ductility, which allows the fins to have more flexibility. This means the fins are more likely to stay intact during a soft. and hard landing without cracking as compared to previously used materials like carbon fiber and wood. However, wood is being used for the bulkheads, specifically ¼ inch plywood. Plywood is much cheaper than fiberglass and it can meet expected standards of performance at maximum thrust. The use of plywood has also been proven to be more efficient in manufacturing the bulkheads using the machinery we have at hand, such as the laser cutter, since we have already cut bulkheads using plywood for the subscale launch in relatively short time. The materials being used for the the body tubes and the nose cone is G12 fiberglass. This means our team has the ability to have more test launches with the same materials since the overall exterior of the rocket has high durability, thus G12 fiberglass is the best choice for our final launch.
- 26. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 25 of 92 3.4.5.3. Motor Mounting and Retention Motor mounting shall be undertaken by our mentor and NAR Level II Member Joseph Mattingly. No other personnel on the team is allowed to handle the motor as it would be a huge safety risk and Joseph Mattingly is the only person qualified within our team to build and mount a rocket motor. To view our retention system and analysis, please refer to section 3.4.3. 3.4.5.4. Mass Statement The mass of the launch vehicle is depicted in the figure below. The different categories are defined by what purpose they serve in the launch vehicle’s performance. Combined, all the components of the vehicle have a total mass of 9747.6 grams. This is an educated estimation of what the total mass of the rocket will vary. Of course, this mass estimation isn’t absolute, since a growth of 25- 33% was accounted for since the submission of the Project Proposal. Currently, a more complete Mass Statement with the weight of every manufactured and purchased component is being undertaken.
- 27. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 26 of 92 3.5. Subscale Flight Results 3.5.1. Flight Data Found below is our OpenRocket Simulation that allowed us to design a subscale with similar specifications and design features. The figures below demonstrate the successful launch and recovery of the subscale launch vehicle. The first figure depicts the constant voltage supply from the 9-volt batteries to the altimeters, with the exception at the times in which current was diverted onto the blasting charges for the deployment of each parachute. Cross-checking the deployment times with the second figure, it is visible that both deployments occurred at the right altitudes recorded by the Stratologgers. The subscale launch vehicle attained a maximum altitude of 2113 ft., with the assistance of fully deployed scaled models of the ATS tab designs. The additional drag generated by these tabs disrupting the flow all throughout the flight reduced the expected apogee significantly.
- 28. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 27 of 92 3.5.2. Result Discussion The figure below demonstrates an apogee 2506 ft., which is 393 ft. higher than the experimental results with full deployment of the subscale ATS. This is a 15% reduction in altitude generated from the additional drag generated from the disturbance of the laminar flow around the body of the launch vehicle, sufficient enough to compensate for any unexpected variations in atmospheric conditions, mass margin errors, and other unpredictable phenomena. The experimental flight also provided us feedback on aspects that need to be deemed of high importance to guarantee the safe operation of the launch vehicle such as the audible feedback from the altimeters, battery life, accessibility of all the switches, and the ease of separation of the multiple segments of the launch vehicle.
- 29. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 28 of 92 3.5.3. Impact on Full Scale Throughout the manufacturing and assembling process of the subscale, many of the designs resulted impractical and mechanically more complex than expected, thus major redesigns had to occur in order to guarantee the functionality of all subsystems. The avionics bay wiring created many issues for assembling the subscale due to the lack of available space within the avionics bay, and thus cable management will be one of the priorities for the assembling procedures of this section of the launch vehicle. Other changes were the position of the GPS, the power supplies, and the key switches, since many of this caused a complication for the time of assembly and pre-launch checks. Another area that was subject to change was the fin assembly method, since the impracticality of having fin braces was not outweighed by its benefit, and so the attachment points for the fins were increased in surface area contact which also reduces the overall weight of the booster section. The positioning of the payload bay was also reworked, due to the volume constraints for the parachute packing and preparation for launch; thus more space will be allocated to enclosing both parachutes along with their respective shockcord and insulator. Pre-flight checklists will also be essential to the success of the full scale test launch, since the assembly of such vehicle requires numerous steps. Pre-checking every subsystem and every
- 30. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 29 of 92 electronic system must be done with plenty of anticipation to ensure that everything is working perfectly and to avoid any last minute inconveniences at the launch pad. Most importantly, the aerodynamic effect of the ATS proved itself to be significant enough to justify the complexity of the design, even with only two deployed tabs rather than the full 4-tab configuration. The mechanical component of these tabs was reworked due to the confined space and mass limitations encountered during subscale manufacturing. The structural soundness of the airframe was also compromised within safe boundaries, but appropriate design changes were accommodated to minimize the added risk of multiple incisions on the structure.
- 31. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 30 of 92 3.6. Recovery Subsystem 3.6.1. Recovery System Hardware The main parachute of diameter 50” will be housed in the avionics section, while the drogue parachute will be located just below the avionics section (using the nosecone as a reference location). Both parachutes will be fabricated from rip-stop nylon in order to support the weight of the launch vehicle. Parachutes will be secured in their individual sections using an insulated material to prevent the ignition of the nylon due to explosive charges that will separate the different sections of the rocket sections during descent deployed from the blasting caps that are attached to 4.85” diameter bulkheads which seal the avionics bay from the rest of the rocket’s compartments. The parachutes will be attached and secured to the rocket via the shock-cords which are connected to U-bolts installed onto the respective bulkheads/centering rings insulating each section of the rocket from pressurization. Parachute Diameter (inches) Main 50 Drogue 15 3.6.2. Electrical Hardware The StratologgerCF altimeter records data at a rate of 20 samples per second and stores it for later use. They also include a Data I/O connector which allows for real-time altimeter data to be sent to
- 32. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 31 of 92 the onboard flight computer. This altimeter is functional up to an altitude of 100,000 feet and will be used to deploy the main and drogue parachutes upon reaching specified altitude. 3.6.3. Kinetic Energy Calculations The total mass of the launch vehicle is given as 9747.6 grams. The nose cone will be made fiberglass and has a weight of 214.74g or 0.47lb. The rocket’s propulsion system/booster section accounts for 22.94% of the overall mass of the launch vehicles as shown in the chart below. The weight of the booster section after the propellant has been expended was estimated at 1.5 lbs The equations below were used to estimate the ideal impact velocity, v of the launch vehicle assuming no external forces. KE = ½ mv2 Where v is the ground hit velocity of the launch vehicle, 10.6m/s or 34.77ft/s. Sections Dry Mass (lbs) KE (ft-lbf) Nosecone 0.47 8.83 Avionics 2.2 35.44 Booster 1.5 28.18 Total 72.45
- 33. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 32 of 92 3.7. Mission Performance Predictions 3.7.1. Validity of Analysis Due to the design compromises made during the subscale launch, the validation of the drag coefficient and effect of the ATS on the rocket could not be conducted. We did acquire promising data to the subsections usage and will further pursue experimentation with a new deployment system and placement on the rocket. The ATS has been placed 18 inches from the bottom of the rocket to accommodate the motor driven system. With the new position, we must investigate any effects the turbulent flow will possible have on the stability of the rocket To illustrate the effect of the ATS on the rocket, we have used CFD analysis from Ansys Fluent 16.2. An attempt was made to use the Flow Simulation add in of Solidworks 2015 for convenience and validation, but the results were highly unreliable. Ansys provided us with answers fairly similar to the original CFD files. When we take a look at the effects of the turbulent kinetic energy, it’s possible to see how raising the flaps of the ATS by approximately 10 inches has created a wake of turbulent flow interrupting the laminar flow to the fins. This increases our overall drag by increasing pressure drag. The pressure contour below shows the mixing of the low and high pressures around the flaps creating our turbulent flow.
- 34. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 33 of 92 3.7.2. Drag Assessment
- 35. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 34 of 92 3.8. Future Testing Component Test Verification Method Lead Screw with DC motor actuation Extension force of flaps test. Quantitative Analysis ATS Wind tunnel testing to confirm Cd simulations. Quantitative Analysis Thrust Plate Bend test and pressure test to verify rigidity until breaking point. Quantitative Analysis Payload Bay Payload retention force measurement test. Quantitative Analysis Avionics Bay Altimeter accuracy and accelerometer performance test. Quantitative Analysis Recovery System Recovery system ground test fire. Inspection Fins Fin attachment robustness test along two axis. Quantitative Analysis Launch Vehicle Assembly Vehicle will be completely assembled under a time constraint to verify efficiency and effectiveness. Inspection
- 36. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 35 of 92 3.9. Launch Procedures 3.9.1. Launch Checklist Below is a preliminary checklist of all the procedures and steps to follow to have a successful and safe launch. Prepare Payload Recovery System Ensure batteries and switches are wired correctly Ensure batteries, power supply, switches, microprocessor, GPS, XBee is/are wired correctly Install and secure fresh batteries into battery holders Insert payload recovery electronics into payload recovery bay Connect appropriate wires Arm altimeter with output shorted to verify jumper settings. This is done to verify battery power and continuity Disarm Altimeter, un-short outputs Insert Payload Recovery Bay into Payload Section Prepare Body Recovery System Ensure batteries and switches are wired correctly Ensure batteries, power supply, switches, microprocessor, GPS, XBee is/are wired correctly Install and secure fresh batteries into battery holders Insert body recovery electronics into payload recovery bay Connect appropriate wires Arm altimeter with output shorted to verify jumper settings. This is done to verify battery power and continuity Disarm Altimeter, un-short outputs Insert Body Recovery Bay into Payload Section Assemble Charges Test e-match resistance to see if it is within specifications Remove protective cover from e-match
- 37. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 36 of 92 Measure amount of black powder used in testing Place e-match on tape with sticky side up Pour black powder over e-match Seal Tape Re-test e-match Check Altimeters Ensure altimeters are disarmed Connect charges to ejection wells Turn on altimeters to verify continuity Disarm altimeters Pack Parachutes Connect drogue shock cord to booster section and body section Attach drogue parachute to drogue shock cord Pack drogue parachute Fold excess shock cord so it does not tangle Attach Nomex cloth to shock cord so it will enclose and shield the parachute while exposing only the Kevlar shock cord to ejection charge Insert cellulose wadding into drogue parachute bay between ejection charges and parachute Insert drogue parachute and shock cord into drogue parachute bay Insert booster section into lower body section, and secure with shear pins Attach main parachute shock cord to upper body section and lower payload parachute bay Attach main parachute to main parachute shock cord Pack main parachute Fold excess shock cord so it does not tangle Attach Nomex cloth to shock cord so it will enclose and shield the parachute while exposing only the Kevlar shock cord to ejection charge Insert cellulose wadding into main parachute bay between ejection charges and parachute
- 38. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 37 of 92 Insert main parachute and shock cord into main parachute bay and Insert upper body section into the lower section of the payload parachute bay, and secure with shear pins Attach payload parachute shock cord to payload section Attach parachute to the end of the payload parachute shock cord Pack payload section parachute Fold excess shock cord so it does not tangle Attach Nomex cloth to shock cord so it will enclose and shield the parachute while exposing only the Kevlar shock cord to ejection charge Insert cellulose wadding into upper payload parachute bay between ejection charges and parachute Insert drogue parachute and shock cord into upper payload parachute bay Insert payload section into payload parachute bay and secure with shear pins Assemble motor Follow manufacturer’s instructions Do not get grease on propellant grains or delay grain Do not install igniter Install Motor in launch vehicle Secure motor retention system Launch Vehicle Prep Inspect launch vehicle, check CG and make sure it is within specified range Bring launch vehicle to Range Safety Officer(RSO) for inspection Bring launch vehicle to Autonomous Ground Support Equipment(AGSE) platform Install launch vehicle on AGSE Install motor igniter on AGSE Touch igniter clips together to make sure they will not fire the igniter when connected Make sure igniter clips are not shorted to each other or any section of the AGSE Connect igniter clips to motor igniter
- 39. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 38 of 92 AGSE Prep Activate AGSE master switch and ensure safety light is flashing in color Activate AGSE pause switch and ensure safety light is solid in color All nonessential personnel evacuate to safe launch distance Deactivate AGSE pause switch and start stopwatch to time AGSE routines Stop stopwatch when AGSE routines are complete and record time from pause switch deactivation to rocket erection Essential personnel will arm altimeters via switches and ensure continuity All personnel will evacuate to safe launch distance Launch Watch flight so launch vehicle sections do not get lost Post Launch Payload/Vehicle Recovery Recover Payload Section and tethered Body/Booster Section Disarm Altimeters if there are unfired charges Disassemble launch vehicle, clean motor case, other parts, and inspect for damage Record altimeter data
- 40. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 39 of 92 3.10. Safety and Environment 3.10.1. Overview Team A.R.E.S. is dedicated to maintaining safe operating conditions for all team members and anyone involved in competition activities. Under the tutelage of the Safety Officer, Team A.R.E.S. will undergo rigorous safety briefings to ensure the integrity and safety of the entire team and equipment is unchanged. During manufacturing, fabrication, and testing of rocket vehicle and AGSE components, it is important to identify the hazards of your environment, and how following safety procedures and protocols can prevent accident and injury to oneself or damage to competition hardware. When working with construction equipment, Team A.R.E.S. members are instructed to work in minimum team sizes of two. This ensures that one team member would be available to provide immediate assistance or quickly get help should an incident occur while using the equipment. The Invention Studio, where team members use the necessary equipment for manufacturing and fabrication, is equipped with first aid kits, fire extinguishers, safety glasses, and expert supervision for the use of all equipment. During physical testing of the rocket structure, and during ejection charge testing, team members will wear safety glasses, have a first aid kit and fire extinguisher on hand, and have licensed safety officials present. In order to use the machines, all team members have been briefed on the proper protocols and procedures of using the lab machines. Risk identification and mitigation techniques are used to assess the dangers of tools and activities to personnel, and how they may create safe operating conditions. To that end, Table XX lists the procedure to identify what hazards and risks may exist and how to minimize the chances of occurrence. Step Name Step Definition 1. Hazard Identification Team will collectively brainstorm to identify any possible hazards that the team may encounter. 2. Risk and Hazard Assessment Team will determine the severity and probability of consequences in case the hazard were to be encountered. How to approach each hazard will also be reviewed. 3. Risk Control and Elimination After the hazard has been identified and assessed, a plan will be put in place to ensure the hazard will not occur. 4. Reviewing Assessments The entire process will be repeated for any new hazards or existing hazard that needs to be updated.
- 41. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 40 of 92 3.10.2. Failure Modes and Analysis The following table entails the information on the general risks that the team may experience while constructing the rocket. The table goes through the severity, likelihood, and prevention methods for each hazard. Hazard Severity Likelihood Mitigation & Control Batteries Explode Burns, skin and eye irritation Low Wear safety glasses and gloves when handling. Make sure no shorts exist in circuits using batteries. If battery gets too hot, stop its use and disconnect it from any circuits. Black Powder Explosions, burns, skin and eye irritation Medium Wear safety glasses, gloves when handling black powder. Be careful when pouring black powder. Operate in a static-free environment Dremel Cuts and scrapes Medium Only operate tools with supervision of teammates. Use tools in appropriate manner. Wear safety glasses to prevent debris from getting into eyes. Power Tools Cuts, punctures, and scrapes Medium Only operate power tools with supervision of teammates. Use tools in appropriate manner. Wear safety glasses to prevent debris from getting into eyes. Epoxy/Glue Toxic fumes, skin and eye irritation High Wear gloves, nitrile for epoxy, face masks, and safety glasses. Work in well ventilated area. Exacto/Craft Knives Cuts, serious/fatal injury Medium Only use knives with teammate supervision. Only use tools in appropriate manner. Do not cut in the direction towards oneself.
- 42. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 41 of 92 Fire Burns, serious/fatal injury Low Keep a fire extinguisher nearby. If an object becomes too hot, or does start a fire, remove power (if applicable) and be prepared to use the fire extinguisher. Hammers Bruises, serious/fatal injury Medium Be aware of where you are swinging the hammer, so that it does not hit yourself, others, or could bounce and hit someone. Hand Saws Cuts, serious/fatal injury Medium Only use saws with teammate supervision. Only use tools in appropriate manner. Wear safety glasses to prevent debris from getting in eyes. Waterjet Cutter Cuts, serious/fatal injury, flying debris Low Only operate under supervision of Undergraduate/Graduate Learning Instructors, and with other teammates. Follow proper operating procedures, wear safety glasses. Improper dress during construction Cuts, serious/fatal injury High Wear closed toed shoes, tie back long hair, do not wear baggy clothing. Power Supply Electrocution, serious/fatal injury Medium Only operate power supply with teammate supervision. Turn off power supply when working with circuitry.
- 43. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 42 of 92 The following table entails the potential failure modes that may be experienced by the Launch Vehicle team and the prevention method for each failure mode. Potential Failure Effects of Failure Failure Prevention Apogee Targeting System (ATS) Vehicle will not reach target altitude Test ATS using subscale launch vehicles Body structure buckling on takeoff Launch failure, damage to launch vehicle, unable to be reused, flying shrapnel towards personnel/crown Test structure to withstand expected forces at launch with a factor of safety. Have proper sized couplers connecting sections. Drogue separation Main parachute will deploy at high speed and may rip or disconnect from vehicle, launch vehicle may become ballistic Perform ground test and flight test. Fins Fins could fall off, causing unstable flight. Fins break or disconnect from launch vehicle, unable to be classified as reusable Test fin at attachment points using expected forces to ensure strength of attachment method. Do not have fins with sharp pointed edges, ensure parachute is large enough to minimize impact kinetic energy, test fin at attachment points using expected forces to ensure strength of attachment. Ignition failure Failure to launch Follow proper procedures when attaching igniter to AGSE. Launch buttons Launch vehicle will separate from rail, causing an unstable flight Ensure launch rail is of proper size to accommodate the buttons, ensure buttons slide easily into rail. Main parachute separation High impact velocity may damage vehicle and make it unrecoverable, vehicle may become ballistic causing serious injury or death Perform ground test and flight test to ensure veracity of deployment method. Motor failure Motor explodes, damaging launch vehicle/AGSE beyond repair Follow NAR regulations and manufacturer’s instructions when
- 44. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 43 of 92 assembling motor. Assemble motor under supervision. Motor retention Motor casing falls out, lost motor case, could damage persons/property Test reliability of motor retention system Payload separation Main parachute may not deploy correctly, higher impact velocity may damage launch vehicle, or cause personal/property damage Perform ground and flight test to ensure veracity of deployment method Thrust plate failure Motor goes through vehicle, damage to vehicle, causing it to be not reusable Test plate and attachment method to withstand expected launch forces with a factor of safety The following table entails the potential failure modes that may be experienced by the AGSE subteam and the prevention method for each failure mode. Potential Failure Effects of Failure Failure Prevention Payload is not secured in bay Payload will bounce inside payload bay, disrupting flight Test various plastic clip dimensions to find best fit RES is not stable while raising Rocket will not be raised, and potentially the motors will be broken Test subsystem, add counterweights to reduce necessary force from motor, and add more framing to increase stability RES does not stay upright Launch vehicle will fall unpredictably Perfect ratchet system, ensure tension in steel cable Electronics short circuit or are overloaded System will lose control Fuses will protect electronics, subscale testing will prevent short circuits and overloads
- 45. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 44 of 92 3.10.3. Personnel Hazards Personal injuries can occur at any given time throughout the entire project. Each individual should be aware and alert at all times when working on the rocket. Warning labels on hazardous materials should be thoroughly read. Equipment should only be used with authorized personnel present. Each team member should be familiar with the safety hazards and prevention methods listed in this document as well as in the safety handbook provided by NASA. Every team member understands that the safety guidelines and procedures outlined must be followed at all times. Failure to do so may result in injury and/or death. 3.10.4. Environmental Concerns The team understands that building a rocket requires the use of many equipment and/or materials throughout the entire design process. Despite the complexity of building a rocket, the environment must be taken into account at all times. Hazardous materials must be properly disposed of. Launches may only take place on authorized days and times. The Material Safety Data Sheet (MSDS) for each material used must be thoroughly read by each team member. Team ARES will do its best to ensure that the negative impact on the environment is at a minimum while designing the launch vehicle.
- 46. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 45 of 92
- 47. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 46 of 92 4. Flight Systems 4.1. Overview The onboard Flight Software was designed to be modular in order to maximize performance while also making it easy for the team to work on it cooperatively. A Scheduler function, which can be reviewed in Appendix XX, determines the frequency at which each block of code runs in reference to the other blocks. The process of scheduling the blocks of code begins with polling the sensors. This code block outputs an altitude and acceleration vector which is then input into the State Estimation block. The State Estimation block runs five times for every single time the sensors are polled. This process allows the State Estimation block to compare the sensed data to the ideal path of the rocket. This process continues 20 times before the controller code block is scheduled. Based on the estimated state, the Controller outputs whether to actuate or not. The Controller, and thus the Actuator, block runs every 100th time the state is estimated and every 20th time the sensors are polled The scheduling process allows the team the opportunity to choose how often the ATS is triggered as well as how much data is gathered before adjusting flight path. The altitude and acceleration data gathered during the sensor polling code block ultimately drive the decisions made throughout the rest of the code and lead to the decision of whether to correct flight path or not.
- 48. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 47 of 92
- 49. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 48 of 92 4.2. Simulink Design Overview This is the general form of our simulink model. This Simulink model aim to help us first Simulate the program and help us to design the motor we want and need. Also, this simulink allow us to design the controller for this system. Here is the General Simulink model we have: We can see the controller and the system block. In this section, we are going to present the Rocket block. We have implemented a Simulink model for the equations of the rocket. Briefly, we have: weight, engine thrust, plates drag, and rocket drag acting on the rocket. So, we created these forces, summed them (with the adequate projection) and then thanks to Newton’s second law we know that this net sum equals the mass of the rocket times its acceleration.
- 50. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 49 of 92
- 51. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 50 of 92 In this diagram, we modeled the engine by computing a function depending only on the time. From this function we are then able to compute the mass ejected by the motor since launch and the thrust level. Please find the Simulink model of the motor below: 4.3. Controller Design Overview 4.3.1. Control Technique The objective of the control here is to reach the exact apogee using flaps. Indeed, the flaps are going to be extended depending on the relative position of the rocket and a “nominal” trajectory pre generated by simulation. The nominal trajectory generated is generated using the equation of the motion of the rocket: then we know that in the absence of perturbation it is exactly the motion that the rocket should have and so we know that this trajectory is perfectly doable by the system, Please see below an example of a nominal trajectory used for the subscale launch.
- 52. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 51 of 92 Once this nominal trajectory generated, we are going to implement a controller such that the error between the current altitude and the nominal altitude goes to zero as t goes to infinity. For that, we will use here a system of flaps. The control authority we have here is therefore: either extend the flaps and create more drag, either not extend the flaps and create less drag. With this technique the rocket will then be able to reach an apogee that is close to the one we want even with the presence of perturbation. 4.3.2. Sliding Mode Control Let u be the area of the flaps we want. This will be our control input. After deriving the equations of motion, we found that implementing a Sliding Mode controller applies very well at the equations. Therefore, we will then use a Sliding Mode Control to control the rocket. The control law we used is then:
- 53. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 52 of 92 With the following: Where : x1 = relative altitude of the rocket from nominal trajectory x2 = relative vertical speed of the rocket from nominal vertical speed hp = nominal vertical speed Crocket = drag coefficient of the rocket body Sr = Surface of the rocket that drags Cflaps = drag coefficient of the flaps Spo = Surface of the flaps half-extended ρ = density of the air For more information, please see Appendix XX, written by a Graduate student member.
- 54. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 53 of 92 5. AGSE Criteria 5.1. AGSE Summary Team ARES’ Autonomous Ground Support Equipment (AGSE) mission will be to secure the payload, raise the launch vehicle, and insert the igniter. The AGSE weighs a total of 60 lbs, has a 10 ft. by 4 ft. base, and a starting height of 1.5 ft. The Robotic Payload Delivery System (RPDS), using 4 servo motors, will deliver and secure the payload inside the payload bay of the launch vehicle. The Rocket Erection System (RES), actuated by a bipolar stepper motor, will raise the launch vehicle from a horizontal position to a position 5 degrees from the vertical. The Motor Ignition System (MIS) will use a rack and pinion system powered by a unipolar stepper motor to insert the igniter. All the functions of the AGSE will be controlled by an Arduino Uno.
- 55. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 54 of 92 5.2. Design Review of AGSE Equipment 5.2.1. Robotic Payload Delivery System (RPDS) 5.2.1.1. Drawings and Specifications
- 56. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 55 of 92 5.2.1.2. Analysis Results The Rapid Payload Delivery System was designed to be extremely simple, at a very low budget, and yet efficient in its movements. Inserting the payload into the payload bay in the launch vehicle requires precision, however, it does not require a significant amount of mechanical tolerance for
- 57. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 56 of 92 failure, as the payload weight is 5 oz. To follow these design features, the robotic arm’s servo motor mounts will be 3D printed in ABS plastic and the struts will be laser cutted out of plywood. Inside the launch vehicle, there is a simple locking mechanical component (shown in the previous section) to ensure there is no payload movement during flight. The locking mechanism will be 3D printed and its plastic material properties allow a secure lock after deformation. Although, the task of the RPDS is relatively simple, it requires precision. As a result, infrared sensors will be implemented into mechanical structure of the claw of the robotic arm, so as to locate the payload and its delivery position. 5.2.1.3. Integrity of Design As explained above, the key of the RPDS design is simplicity. However, various problems may arise from adopting a simple mechanical system. One aspect to consider wisely is the materials used. During the manufacturing and assembly process of the robotic arm, problems with the strength of the 3D printed servo mounts were encountered. ABS plastic proved to be relatively brittle, and thus forced the design of the mount to change and account for the stresses applied to the part. If the 3D printed components continue to fail mechanically, these components will be manufactured through milling operations on a delrin stock. Again, the RPDS was design to be minimalistic and cheap. However, if this design encounters more problems with the manufacturing and assembly process, it shall be forced to change dramatically. This change will result in the purchase and use of stronger servo motors or robotic arm kits.
- 58. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 57 of 92 5.2.2. Rocket Erector System (RES) 5.2.2.1. Drawings and Specifications
- 59. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 58 of 92 5.2.2.2. Analysis Results The launch vehicle is raised from a horizontal position to 5 degrees off of the vertical position using the force of a stepper motor winding a spool of cable around a pulley system. A cable/pulley system is an easy way to manipulate the direction vector of force, and allow for lifting the Launch Vehicle in a controlled manner. The stepper motor provides enough torque to rotate the spool to wind the cable, thus raising the launch vehicle. The stepper motor is fastened to the frame using T-nuts. The spool is attached to the stepper motor using a force fitted coupler. The coupler is secured inside the spool with screws. The cable is fastened to the spool using a tightened hose clamp. Then it is strung upwards around a pulley, which is also connected to the vertical part of the frame using T-nuts, and then tied and clamped to a fixed eye screw on the lifting rod across the length of the frame. As the stepper motor rotates the spool, the cable is wound around the spool causing tension to pull the lifting rod and raise the launch vehicle. 5.2.2.3. Integrity of Design The stepper motor winding the cable around a spool to create pulling tension on the lifting rod is strong enough to lift. the Launch Vehicle from a horizontal position to 5 degrees off of the vertical position. The stepper motor provides ample torque, and the steel cable can withstand a much larger force than the amount needed to lift. the launch vehicle. However, a taut cable is not extremely stable, and the launch vehicle or cable may rock during raising. The frame has a wide base to help fight potential instability. After determining the cable’s stability in testing, a cable guide may be added to the design if needed. Having the cable be strung upwards around the single pulley and tied to the lifting rod on the other end of the frame puts a lot of of stress on the pulley and the T- nuts it is fastened to the frame with. If the pulley appears to be under too much stress during testing, a second pulley will be added to the system to relieve tension from the original single pulley. The cable will then be strung upwards and interweaved between the two pulleys before it reaches the lifting rod.
- 60. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 59 of 92 5.2.3. MIS 5.2.3.1. Drawings and Specifications
- 61. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 60 of 92 5.2.3.2. Analysis Results This rack and pinion system was chosen for its reliability. With both the guide pieces and ball bearings, the rack is accurately moved into the motor cavity. The guides and the bearings keep the rack steady as the pinion rotates. The steel used to construct the subsystem also helps act as counterweight when raising the launch vehicle. The guide rails are held in place by the steel side pieces which are fastened to the end of the main rail. The rack can extend to 1.5 ft. past its starting position.
- 62. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 61 of 92 5.2.3.3. Integrity of Design The design’s strength comes from its ease of construction. The steel guides and sides can be manufactured using a water jet. The water jet ensures greater accuracy than many other machining methods during construction. The pieces can be quickly assembled by fitting the guides into the sides, then the sides to the rail using standard fasteners. The steel sides have multiple holes for bolts so they will be stable along the rail. More guides may have to be added if the rack is not stable enough during motion. Another possibility is that the guides contribute too much friction. Then, a new guide design may have to be created. Future redesign may also be necessary if a coupler is needed for the stepper motor.
- 63. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 62 of 92 5.2.4. Electronics 5.2.4.1. Drawings and Specifications
- 64. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 63 of 92 5.2.4.2. Analysis Results The unipolar stepper motor is used to raise the Launch Vehicle, and the bipolar stepper motor is used to power the MIS. The 5 servo motors comprise of the 4 degrees of rotation of the arm and the claw. Each major component of the AGSE has its own green and red LED to indicate whether that specific task has been accomplished. The yellow LED only turns on when the entire system is in the pause state. The emergency kill switch will be connected between the battery and the Arduino, so it directly cuts the power to the entire system. An Arduino Mega was chosen because it contains enough digital inputs and outputs while also providing the necessary 5V of operating voltage. It was also the cheapest option of all the microcontrollers that met those guidelines. Component Quantity Unipolar Stepper Motor 1 Bipolar Stepper Motor 1 Servo Motors (Tower Pro MG 995) 5 LEDs 7 (3 Red, 3 Green, 1 Yellow) Arduino Mega 2560 - R3 1 Stepper Motor Drivers - (ROB-12779) 2 Emergency Kill Switch 1 Start/Pause Button 1 Electronics Box 1 Resistors and Wires As Needed
- 65. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 64 of 92 5.2.4.3. Integrity of Design The design for the RPDS can accurately capture, secure, and deliver the payload because of the arm design. The 4 degrees of rotation that the arms has enables it to move in any direction, so the payload can be placed anywhere within the certain distance. The plastic clips have been tested, so they can secure the payload without letting it move. The design for the REM is simple, but testing for this part has not begun. The ending angle of the rail will be hard-coded into the Arduino, so there is less room for error during this phase. Extensive testing will be needed to ensure the accuracy of this step. The same can also be said about the MIS because the distance the igniter moves will also be hard-coded into the Arduino. After the REM is finished, the rail needs to maintain its position at the final angle. In order to do this, the Arduino must constantly monitor the angle of the rail, in case the rail starts to fall under its own weight. 5.3. Mission Success Criteria and Functional Requirements Requirement Design Feature Requirement Verification Success Criteria Capture the payload Robotic arm with IR sensors will locate and grip the payload Visual inspection The payload stays in the grip of the claw Move the payload into the payload bay located in the Launch Vehicle Robotic arm will have 4 DOF controlled by 4 servo motors Visual inspection The arm moves with speed and stability and the payload stays in the grip of the claw Secure payload in payload bay Plastic clips will snap around the payload Visual and audio inspection (from snapping sound of plastic clips) The payload does not fall out of the pay Raise the Launch Vehicle A cable and spool system will pull the guide rail upwards to appropriate angle Visual inspection and touch sensor feedback The Launch Vehicle moves from a horizontal position to 5 degrees from the vertical
- 66. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 65 of 92 Maintain the Launch Vehicle angle A ratchet system will ensure the Launch Vehicle can only move upwards Visual inspection and audio inspection (from clanking noise of ratchet locking) The Launch Vehicle does not fall down Insert the igniter A rack and pinion system will move the electronic match into the motor cavity Visual inspection The igniter is inserted 1 ft. into the motor cavity 5.4. Manufacturing Approach 5.4.1. Overall Manufacturing Approach Mission success will be achieved by building a reliable and stable design. Before any actual manufacturing, the sub-team leader and the team leader must look over the plans. This allows for any mistakes to be caught before materials are wasted. In order to best achieve this, the parts used in the AGSE will be manufactured from computer controlled machines, including: water jet, laser cutter, and 3-D printer. By using these tools, greater accuracy can be achieved than machining by hand. Parts that cannot be manufactured in house will be purchased from trusted vendors. With a focus on precise manufacturing, our CAD models will be followed with as little error as possible. This decreases the chances of an improperly produced part which could lead to failure in a subsystem. Using these machines also allows for many parts to be produced at once. These parts can be used as replacement parts if after testing the AGSE, some parts start to wear out. This ensures a sustainable design. 5.4.2. RPDS Accuracy in movement and mechanical strength are the main keys to ensure mission success of the RPDS. The robotic arm is designed in a manner that its materials will not fail during operation. The laser cutted plywood struts are positioned with its face sideways to better support the load in the vertical direction. The laser cutting operation ensures precision in its dimensions and allows easy and fast manufacturing. Because the servo mounts embody a relatively complex shape, it is difficult to manufacture through milling operations. As a result, they are 3D printed in high
- 67. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 66 of 92 quantities, in case any break during operation. The claw is almost entirely made of 3D printed parts, also because they have complex shapes. The design of the claw is very different from ordinary claws found in the market. As a result, the design is subject to constant modification, which is promoted by the easy manufacturing process of 3D printers. 5.4.3. RES The stability and structural integrity of the RES frame and pulley/cable system are key to mission success. The frame is both wider and longer than the Launch Vehicle and other necessary mechanics to increase stability. It is made out of thick T-slotted extrusion beams that are fastened together using T-nuts. The pulley and stepper motor casing are also attached to the frame’s T- slotted beams with T-nuts. The pulley is attached to a vertical part of the frame, and the stepper motor casing is attached to the base of the frame. The stepper motor uses a force fitted coupler to hold the spool. The cable travels from the spool through the pulley, and is connected to an eye screw on the lifting rod on the other side of the frame. The connection of the cable to the lifting rod is crucial to mission success. The cable will be strung through the eye screw, tied and clamped, to ensure that it is properly connected and does not move from its required position. 5.4.4. MIS Mission success for the MIS is highly dependent on accuracy. To maintain a high level of accuracy for the rack and pinion system, all steel pieces will be produced using a computer controlled water jet. The water jet allows all the pieces to be a uniform shape. After the water jet, the pieces will be measured manually to confirm the sizes.
- 68. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 67 of 92 5.4.5. Electronics For construction of the final product, new wires will be used, and the breadboard itself will be tested separately to ensure that there are no broken connections. All the connections to the Arduino and breadboard will be taped to prevent any disconnect, and all the electric components will be in a metal electric box to prevent further disturbances. A fully charged battery will also be used during the competition. 5.5. Remaining Manufacturing and Assembly Subsystem Part Manufacturing Method Estimated Completion Date AGSE Support frame Bandsaw 2/4 RPDS Servo motor mounts 3-D printing 1/21 RPDS Struts Laser cutting 1/21 RES Stepper motor mount 3-D printing 1/21 MIS Steel guides Water jetting 1/26 MIS Steel sides Water jetting 1/26 MIS Steel blast plate Water jetting 1/26 Electronics Electronics containment unit Laser cutting 2/4
- 69. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 68 of 92 5.6. AGSE Electronics 5.6.1. AGSE Electronics Overview The AGSE electronics primarily consists of 2 stepper motors, 5 servo motors, and multiple LEDs and resistors. The bipolar stepper motor will be used for the MIS, the unipolar stepper motor will be used for the RES, and the RPDS will be comprised of the 5 servo motors. An Arduino Mega 2560-R3 is used as the microcontroller for all 3 processes. The entire system is powered by a 12V - 10.5Ah lead acid battery. All the electronic components of the AGSE will be housed in a 2ft. x 1.5ft. x 1ft. metal electrical box.
- 70. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 69 of 92 5.6.2. Drawings and Schematics Schematic of the AGSE electronics including, motors, resistors, the Arduino, and LEDs. The two drivers for the stepper motors need to be connected to a breadboard which is not shown. Other than the servo motors, LEDs, and the stepper motors, every component should be housed in the electronics box as shown in the schematic.
- 71. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 70 of 92 5.6.3. Block Diagrams When the system is powered on and the start button is pressed, the system will activate the RPDS, which finds and delivers the payload to the rocket. After this process is finished, the green LED corresponding to the RPDS will turn on, and the system will activate the REM. After the rocket is raised, the corresponding green LED will turn on, and the MIS will be activated. To ensure the safety of the AGSE is not compromised, there will be emergency stop switches located around each subsystem for the AGSE. For the REM, the emergency-stop switch will be located on the support rail for the main pivot. Figure below displays the emergency stop button location. A similar system will be used for the MIS whereas once the roller switch underneath the rack registers a false, the motor will be stopped. The false indicates that the rack is no longer pressing down on the switch and has moved to its required position.
- 72. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 71 of 92 5.6.4. Batteries/Power Component Quantity Total Operating Current Servo Motor 5 500 mA Unipolar Stepper Motor 1 2000 mA Bipolar Stepper Motor 1 330 mA LED 7 280 mA Pushbutton 1 40 mA Arduino Mega 1 100 mA Based on the previous years’ time: the RES will take 4 minutes, the MIS will take 1 minutes, and the RPDS will take 3 minutes. Using these times and the current shown above, the amount of consumed charge can be calculated per full system run-through: .5(3) + 2(4) + .33(1) + .28(8) + .04(8) + .1(8) = 13.19 / 60 minutes = .2198 Ah for one full run. The battery contains 10.5 Ah, therefore the battery can power 47.76 runs. This translates to 6.37 hours. 5.6.5. Switch and indicator Wattage and Location One of the challenges in coding the Arduino was finding a method of pausing and resuming the code based on the push of a button. The Pause-Button Test was the process used to find the best method of pausing and resuming the Arduino Code. The electronics will be housed in a 2ft. x 1.5ft. x 1 metal electronics box. This box will contain the Arduino, the battery, the breadboard, the resistors, and all the wires. The AGSE Schematic shows the location of all the components inside the electronics box.
- 73. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 72 of 92 5.7. Component Testing 5.7.1. Electronics Pause Button Test The purpose of the Pause-Button Test was to see if a start/pause pushbutton could be implemented to instantaneously stop the Arduino and continue on another press of the button. The challenge was getting the Arduino to continue from where it left. off rather than repeat the operation it was on. This was solved by converting single lines of code into loops. For example, instead of rotating a servo motor to 100 degrees, the code would incrementally loop to 100 in increments of 1 degree. Loops allow the Arduino to constantly monitor the state of the button, thereby allowing it to continue from where it left. off. After this change was made, the button worked as it should. In the figure above, when the button was pressed, the servo motor was moving to a certain degree. The servo stopped immediately, and on the next press, it resumed moving to that same degree. Please refer to Appendix XX, for the test plan with more details concerning the set up and experimental
- 74. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 73 of 92 5.7.2. RES Lifting Test The main purpose of this test is [Appendix XX] to ensure the RES mechanism has the ability to lift. the launch vehicle, to ensure the cable and framing is safely stabilized, to ensure the individual components (this includes the stepper motor, the motor casing, the spool, the pulley, the cable, and the eye screw) are durable enough to withstand the forces involved with lifting the launch vehicle, to ensure the launch vehicle could be lifted in a safe but efficient rate of speed, and to determine the most effective position for the pulley to be placed on the frame to yield the most torque on the lifting rod. During the testing, the RES will attempt to lift. the launch vehicle as quickly as it can as well as hold the launch vehicle at different positions (15, 30, 45, 60, 85 degrees) in between the horizontal and 5 degrees off of the vertical. It will help determine if the cable or frame needs more stability support. If so, a guide will be added to the cable’s path and more framing will be added to the base of the existing frame. The height of the pulley position will be varied during testing to determine optimal torque. If the RES is not able to lift. the launch vehicle because of strength and durability issues, more pulleys will be added to the frame to help distribute the force of tension. The cable would then be intertwined between the pulleys, thus making it easier for the RES to lift. the launch vehicle. 5.7.3. RPDS Payload Insertion Test The payload insertion test proves the strength capability of the robotic arm and its precision to accomplish the task. The test is simple and direct. A payload is placed approximately a foot away from the robotic arm. The arm then approaches the payload, grabs it with the claw, moves it above the locking component and finally presses it into the lock. This test can be formed in two different ways. Either through predetermined movements by the servo motors, or through constant feedback from ultrasonic sensor readings. If the option of the usage of sensors is optimized through trials and better programming algorithms, it shall be the adequate method for the robotic arm movement. The ultrasonic sensor will only be used to locate the payload and the locking component.
- 75. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 74 of 92 Because the servo motors’ movements are relatively accurate, it is possible that a hardcoded movement can outperforms the movement with distance feedbacks. However, the aim is to perfect the algorithm to search for the payload and its securing component. Additionally, it is expected that the servo motors used are capable of moving the payload with relative ease. If the servo motors don’t have enough torque to perform its task, stronger motors are to be used. 5.8. Integration Plan The AGSE and the Launch Vehicle interface at two specific points, the payload hatch and the Launch Vehicle rail. The payload hatch interacts directly with the RPDS. The RPDS must be able to navigate within the hatch to place the payload. To allow this, the hatch will have an opening 2.9 inches wide while the arm has a width of 2.5 in. The RPDS must also have enough strength to snap the payload into the clips inside the bay. This will be done by adjusting the strength of the clips after testing. Finally the RPDS must be able to close the hatch. The closing method was simplified by adding a magnetic lock to the hatch. The RPDS must simply move the hatch forward with its wrist motion to begin closing and the magnets will finish the closing process. The other part of the AGSE-Launch Vehicle interface is the launch rail. The Launch Vehicle will first be secured using rail buttons on the rocket. These rail buttons will prevent the Launch vehicle from moving perpendicular to the rail. To prevent rotational motion, steel extrusions along the rail will hold the Launch Vehicle’s fins at a fixed angle. To prevent motion up and down the rail, a steel plate will be placed near the end of the rail (but in front of the MIS) to stop the Launch Vehicle from sliding. These additions to the rail will only allow the Launch Vehicle to move up the rail, restricting unwanted motion.
- 76. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 75 of 92 5.9. Failure and Safety Analysis Potential Failure Effects of Failure Failure Prevention Payload is not secured in bay Payload will bounce inside payload bay, disrupting flight Test various plastic clip dimensions to find best fit RPDS stuck inside payload bay Payload bay will not close and RPDS will be destroyed by raising of the launch vehicle RES will be started by a signal from the RPDS after it has completed its task Launch Vehicle moves uncontrollably on the rail Could disrupt performance of other subsystems More support along the launch rail to keep the disruptive movement of the launch vehicle at a minimum RES is not stable while raising Rocket will not be raised, and potentially the motors will be broken Test subsystem, add counterweights to reduce necessary force from motor, and add more framing to increase stability RES is not stable at full extension Launch vehicle could tip over Increase the weight to lower the center of gravity. Increase the base width. Add more supports to the launch rail. RES does not stay upright Launch vehicle will fall unpredictably Perfect ratchet system, ensure tension in steel cable RES stepper motor does not stop Tension will continue to increase in the cable leading to failure Emergency stop button in place that activates when rail is at maximum angle MIS stepper motor does not stop Rack will move further into motor cavity, possibly damaging motor Emergency roller switch in place that activates when rack passes a certain distance
- 77. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 76 of 92 Electronics short circuit or are overloaded System will lose control Fuses will protect electronics, subscale testing will prevent short circuits and overloads
- 78. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 77 of 92 6. Project Plan 6.1. Budget Plan The projected project budget is approximately $5.872.38 – below the projected fundraising goal by just over 11%. This cost was derived using the actual project costs from the 2015-2016 NASA SLI competition cycle and a 15% margin was added to the Launch Vehicle and Flight Systems costs during the previous project cycle. The project budget breakdown is listed numerically in Table 6: Budget Summary and graphically in Figure 7. Table 6: Budget Summary Section Cost Avionics $700.00 AGSE $808.60 Launch Vehicle$963.78 Testing $900.00 Motor $1,000.00 Operations $1,000.00 Outreach $500.00 Total Budget $5,872.38 Table XX lists the expenses as of the PDR Milestone. The summary is broken down into five (5) main categories: Launch Vehicle, AGSE, Flight Systems, Operations, and Testing. The Launch Vehicle and Flight Systems categories are further broken down into two (2) subcategories: Flight Hardware and Testing. Operational expenses include: non-system specific test equipment, Team supplies, non-system specific fabrication supplies, as well as any travel and outreach expenses. Any system-specific equipment bought for testing is charged against that specific system. $700.00 $808.60 $963.78 $900.00 $1,000.00 $1,000.00 $500.00 2015-2016 ARES Projected Budget Distribution Avionics AGSE Launch Vehicle Testing Motor Operations Outreach Figure 7: Budget Summary
- 79. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 78 of 92 Table XX: Expenses as of PDR Subsystem Amount Launch Vehicle $75.36 Flight Systems $14.53 AGSE $92.69 Operations $20.00 Testing $2.50 Total $205.08 The Subscale Purchases were roughly around $75.36, include the motor and building the structure. Many parts for the full scale such as the fiber glass body tube have been purchased but until they arrive, they will remain unmarked. 6.2. Funding Plan In order to fund the 2015-2016 competition cycle, Team ARES have sought sponsorships from academic and industry sources. The current sponsors of Team ARES and their predicted contributions can be found in Table XX. Additionally, the Team has also received a dedicated room in which the Team can construct and store their launch vehicle, payload, and other non- explosive components. All explosive components (i.e. black power) are properly stored in Fire Lockers in either the Ben T. Zinn Combustion Laboratory or the Ramblin’ Rocket Club Flammable Safety Cabinet. Furthermore, the Georgia Tech Invention Studio and AE Maker Space will support all fabrication needs of the Team. Sponsor Contribution Date 2014-2015 Unused Funds $1,200 -- Georgia Space Grant Consortium $1,000 Nov 2015 Georgia Tech School of Aerospace Engineering (est.) $1,000 Jan 2015 Georgia Tech Student Gov’t Association (est.) $1,000 Jan 2015 Corporate Donations (est.) $2,000 Feb 2016
- 80. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 79 of 92 Orbital ATK Travel Stipend (est.) $400 Apr 2016 Total $6,600
- 81. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 80 of 92 7. Project Schedule Team ARES project is driven by the design milestones set forth by the NASA SLI Program Office. The design milestones are listed in Table XX. The project Gantt chart for Project Hermes – contains only high-level activities due to the unique launch vehicle and payload designs. A more detailed Critical Path chart is located in Section XX. Deadline Date Team Formation 20 AUG Proposal 11 SEPT Web Presence Established 23 OCT PDR Documentation 6 NOV PDR Teleconference 9-20 NOV CDR Documentation 15 JAN CDR Teleconference 19-29 JAN AGSE, Flight Systems, and Launch Vehicle Testing 29 JAN – 20 FEB Full Scale Testing and Launching 20 FEB FRR Documentation 14 MAR FRR Teleconference 17-30 MAR Competition 13-16 APR PLAR Documentation 29 APR 7.1.1. Critical Path Chart: CDR to PLAR The critical path chart illustrated below demonstrates the highly integrated nature of Project Hermes. The critical path chart identifies: • High Risk Tasks – red boxes • Low-Moderate Risk Tasks – pink boxes
- 82. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 81 of 92 • Earned Value Management (EVM) Goal Tasks – gold boxes • Nominal Tasks – grey boxes • Critical Path – green arrow • Non-Critical Path – black arrows • Current Place on the Critical path – blue outline
- 83. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 82 of 92 Figure: Critical Path Chart from CDR to PLAR A larger version of the critical path discussion can be found in the Appendix XX.
- 84. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 83 of 92 7.2. Schedule Risk Three (3) items have been identified as “High Risk Items.” These are: • Launch Vehicle Recovery System Design • Flight Software Verification • Launch Vehicle & AGSE Systems Design Table XX lists the mitigation for these items: CAPTION FOR TABLE XX High-Risk Task Potential Impact on Project Hermes Mitigation Launch Vehicle & AGSE Design, Fabrication, & Testing 1) Schedule Impact 2) Budgetary Impact 3) Not qualifying for Competition Launch 1) Ensure personnel have direct and free access to experienced personnel on and off of the team 2) Ensure personnel have knowledge to effectively utilize simulation and analysis tools 3) Ensure personnel have direct and free access to the simulation and analysis tools 4) Ensure personnel are familiar with relevant fabrication Recovery System Design, Fabrication, & Testing 1) Excessive kinetic energy during landing resulting in damage to the launch vehicle 2) Failure to deploy drogue and/or main parachute resulting in a high energy impact with the ground destroying the Launch Vehicle 1) Ensure Recovery System Lead has direct and free access to experienced personnel on and off the team 2) Provide real-time feedback of the design decisions to ensure all recovery-related requirements are meet with
- 85. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 84 of 92 at least 5% margin wherever possible 3) Ensure proper manufacturing and packing techniques are utilized during the assembly and fabrication of the recovery system Flight Software Design, Verification, & Testing 1) Incorrect Calculations during flight leads to an inaccurate targeting 2) Flight Systems does not function properly during flight 3) Flight Systems encounters a flight anomaly that results in excessive draw and damage to the Flight Avionics, Power Supply, and/or Launch Vehicle 1) Ensure Flight Software Lead has direct and free access to experienced personnel on and off the team. 2) Thoroughly test the system on the ground with wind tunnels and other testing 3) Develop multiple paths to achieve end goal of developing the robust control logic that is required for the successful demonstration of the Flight System
- 86. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 85 of 92 8. Educational Outreach Plan and Status 8.1. Overview The goal of Georgia Tech’s outreach program is to promote interest in the Science, Technology, Engineering, and Mathematics (STEM) fields. Team A.R.E.S. intends to conduct various outreach programs targeting middle school Students and Educators. Team A.R.E.S. will have an outreach request form on their webpage for Educators to request presentations or hands-on activities for their classroom. The team plans to particularly encourage requests from schools in disadvantaged areas of Atlanta, with the goal of encouraging students there to seek careers in STEM fields. 8.2. Atlanta Maker’s Faire Team ARES had a booth at the Atlanta Makers Fair, a fair in which various craftsman from the community and Georgia Tech assemble to show off their accomplishments. The intent of this program is to give clubs, organizations, and other hobbyists the opportunity to show others their unique creations and skills. The event is open to the entire Atlanta community and had a large attendance this year. The Team ARES booth had a display of our various rockets, as well as a station for children to use stomp rockets. Our booth had 45-60 middle school aged children attend and participate in the stomp rocket activity across the two days. 8.3. First Lego League FIRST Lego League is an engineering competition designed for middle school children in which they build and compete with an autonomous MINDSTORMS robot. Annual competitions are held centered on a theme exploring a real-world problem. Team A.R.E.S. plans to have a booth at the Georgia Tech FIRST Lego League Tournament, with the goal of illustrating how the skills and ideas utilized in the competition translate to real world applications; in particular, a rocket with autonomous capabilities. The team also plans to help judge the tournament.
- 87. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 86 of 92 8.4. CEISMC GT The Center for Education Integrating Science, Mathematics, and Computing (CEISMC) is a partnership uniting the Georgia Institute of Technology with educational groups, schools, corporations, and opinion leaders throughout the state of Georgia. Team ARES is dedicated to the enhancement of STEM education and will look forward to partnering with CEISMC and their events in the near future. 9. Conclusion
- 88. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 87 of 92 Appendix I: Scheduler #include <stdint.h> #include <stdbool.h> #include <stdio.h> /* * Time between running blocks of code. Not based on time but rather how much * each block will run relative to the others. For example, the sensors will be * polled once for every 5 times the state estimator runs. */ static uint16_t POLL_SENSOR_RATE = 5; static uint16_t STATE_ESTIMATE_RATE = 1; static uint16_t CONROLLER_RATE = 100; /* * Variables for holding sensor values, and flags if they have been updated * (Once they are used by the state estimator, they will be set back to false) */ float altitude_sensor; float acceleration_sensor[3]; bool altitude_updated; bool acceleration_updated; /* Estimations of position, velocity, and acceleration */ float position_est[3]; /* added '_est' to show this is an estimation */ float velocity_est[3]; float acceleration_est[3]; /* True if pins are currently deployed, false otherwise */ bool control; /* * Count how many times loop has run. Use to determine when to call different * blocks. unsigned so an overflow won't cause it to go negative. */ uint16_t schedule_counter = 0; /* Function prototypes. Will go in the header file with details */ int scheduler(); int poll_sensors(float *altitude, float *acceleration,
- 89. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 88 of 92 bool *altitude_updated, bool *acceleration_updated); int state_estimate(float altitude, float *acceleration, bool altitude_updated, bool acceleration_updated, float *position_est, float *velocity_est, float *acceleration_est); int controller(float *position_est, float *velocity_est, float *acceleration_est, bool *control); int actuator(bool control); /* * Point of program entry. */ int main() { /* Initalize system */ if (init() < 0) { printf("Failed to initalize.n"); return -1; } /* Run the scheduler endlessly. Minor performance increase * from including the loop inside the function and avoiding * repeated function call overhead. */ if (scheduler() < 0) { printf("Error.n"); return -1; } return 0; } int scheduler() { while(true) { /* * The mod of schedule_counter and the poll rate will be zero when the * functions should be called. For example, if POLL_SENSOR_RATE is 5, * schedule_counter % POLL_SENSOR_RATE will only equal zero when * schedule_counter is 5, 10, 15, ... */ if (!(schedule_counter % POLL_SENSOR_RATE)) {
- 90. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 89 of 92 /* * A standard way of calling functions that may be error * prone. If the return is -1 handle the error, otherwise the * function just ran normally */ if (poll_sensors(&altitude_sensor, acceleration_sensor, &altitude_updated, &acceleration_updated) < 0) { /* Error handling stuff here */ printf("Error polling sensors.n"); return -1; } } if (!(schedule_counter % STATE_ESTIMATE_RATE)) { if (state_estimate(altitude_sensor, acceleration_sensor, altitude_updated, acceleration_updated, position_est, velocity_est, acceleration_est) < 0) { /* Error handling stuff here */ printf("Error estimating state.n"); return -1; } } if (!(schedule_counter % CONROLLER_RATE)) { if (controller(position_est, velocity_est, acceleration_est, &control) < 0) { /* Error handling stuff here */ printf("Error in controller.n"); return -1; } if (actuator(control) < 0) { /* Error handling stuff here */ printf("Error in actuator.n"); return -1; } } /* Note that schedule_counter is an unsigned integer. Once it hits * limit it will just go right back to zero, and zero causes no errors * so no need for bound checks here. */ schedule_counter++; } return 0; }
- 91. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 90 of 92 Appendix II: Gantt Chart
- 92. ID Task Mode Task Name Start Finish 1 NASA SLI Competition Fri 8/7/15 Fri 4/29/16 2 RFP Released by NASA Fri 8/7/15 Fri 9/11/15 3 Proposal Fri 8/7/15 Fri 9/11/15 4 Team Formation Thu 8/20/15 Mon 8/24/15 5 Initial Rocket Design Thu 8/20/15 Thu 9/3/15 6 Initial AGSE Design Thu 8/20/15 Thu 9/3/15 7 Internal Proposal Review Thu 9/3/15 Fri 9/11/15 8 Proposal Submitted Fri 9/11/15 Fri 9/11/15 9 Prelimary Design Review Thu 8/20/15 Fri 11/6/15 10 Launch Vehicle Fri 9/11/15 Fri 10/30/15 11 Avionics Bay Final Design Thu 10/1/15 Thu 10/8/15 12 ATS Final Design Thu 10/1/15 Thu 10/8/15 13 Individual CAD Components Thu 10/1/15 Thu 10/8/15 14 Complete Materials List for Full Scale Fri 10/9/15 Fri 10/16/15 15 FullScale Design Complete Sat 10/17/15 Sat 10/17/15 16 Complete Materials List for Sub Scale Mon 10/19/15 Thu 10/22/15 17 Sub Scale Material Purchase Thu 10/22/15 Thu 10/22/15 18 AGSE Fri 9/11/15 Fri 10/30/15 19 Finalize Overall Design Fri 9/11/15 Thu 10/8/15 20 PLIS Overall Design Fri 9/11/15 Tue 10/6/15 21 REM Overall Design Fri 9/11/15 Tue 10/6/15 22 MIS Overall Design Fri 9/11/15 Tue 10/6/15 NASA SLI Competition Proposal 9/11 Prelimary Design Review Launch Vehicle AGSE E B M E B M E B M E B M E B M E B M E B M E B M E B M E B M August September October November December January February March April May Task Split Milestone Summary Project Summary Inactive Task Inactive Milestone Inactive Summary Manual Task Duration-only Manual Summary Rollup Manual Summary Start-only Finish-only External Tasks External Milestone Deadline Progress Manual Progress Page 1 Project: GC 15 MK 1 Date: Fri 1/15/16
- 93. ID Task Mode Task Name Start Finish 23 AGSE Internal Design Review Fri 10/9/15 Fri 10/9/15 24 Electronic Schematics Fri 9/11/15 Thu 10/8/15 25 Complete Materials List Fri 10/9/15 Tue 10/13/15 26 SubSystem Testing Planning Fri 10/9/15 Thu 10/29/15 27 Prelimaniry PLIS Construction Thu 10/15/15 Thu 10/29/15 28 Flight Systems Fri 9/11/15 Thu 10/29/15 29 Material List Fri 9/18/15 Fri 9/25/15 30 ATS Solenoid Results Fri 9/11/15 Tue 10/6/15 31 Altimeter Data Fri 9/11/15 Mon 10/5/15 32 Electronic Schematics Fri 9/11/15 Thu 10/29/15 33 On the Ground Testing Plans Fri 9/11/15 Thu 10/29/15 34 PDR Review Thu 10/29/15 Thu 11/5/15 35 PDR Submitted Fri 11/6/15 Fri 11/6/15 36 Critical Design Review Mon 11/9/15 Fri 1/15/16 37 Flight Systems Mon 11/9/15 Mon 11/30/15 38 Full Design Implementation Mon 11/9/15 Mon 11/23/15 39 Full Component Testing Mon 11/23/15 Mon 11/30/15 40 Recovery System Test Thu 11/19/15 Thu 11/19/15 41 Launch Vehicle Mon 11/9/15 Fri 1/15/16 42 SubScale Test Launch Mon 11/9/15 Sat 11/21/15 43 Finalize SubScale Design Mon 11/9/15 Wed 11/11/15 44 Purchase Nosecone and 4in Bodytubes Wed 11/11/15 Mon 11/16/15 10/9 Flight Systems 11/6 Critical Design Review Flight Systems 11/19 Launch Vehicle SubScale Test Launch E B M E B M E B M E B M E B M E B M E B M E B M E B M E B M August September October November December January February March April May Task Split Milestone Summary Project Summary Inactive Task Inactive Milestone Inactive Summary Manual Task Duration-only Manual Summary Rollup Manual Summary Start-only Finish-only External Tasks External Milestone Deadline Progress Manual Progress Page 2 Project: GC 15 MK 1 Date: Fri 1/15/16
- 94. ID Task Mode Task Name Start Finish 45 Design DXF File for Bulkheads and Avionics Bay Wed 11/11/15 Fri 11/13/15 46 Manufacture Bulkheads & Avionics Bay Mon 11/16/15 Wed 11/18/15 47 Manufacture Booster Section Mon 11/16/15 Wed 11/18/15 48 Design ATS Subscale Wed 11/11/15 Fri 11/13/15 49 Manufacture ATS Subscale Mon 11/16/15 Wed 11/18/15 50 Design SubScale Payload Bay Wed 11/11/15 Fri 11/13/15 51 Manufacture Payload Bay Mon 11/16/15 Thu 11/19/15 52 Subscale Recovery System Test Thu 11/19/15 Thu 11/19/15 53 SubScale Test Launch Sat 11/21/15 Sat 11/21/15 54 Final Design of Launch Vehicle Mon 11/9/15 Sat 12/12/15 55 ATS Static Ground Testing Mon 11/9/15 Fri 11/13/15 56 ATS Wind Tunnel Testing Mon 11/16/15 Tue 12/8/15 57 Structural Testing Mon 11/30/15 Sat 12/12/15 58 Full Scale Material Purchase Tue 12/1/15 Tue 12/8/15 59 Full Scale Material Purchase Mon 11/16/15 Fri 11/20/15 60 Beginning of Full Scale Construction Mon 1/11/16 Fri 1/15/16 61 Flight Readiness Review Thu 1/14/16 Mon 3/14/16 62 Flight Systems Sat 1/16/16 Mon 3/14/16 63 Avionics Bay Refinement Sat 1/16/16 Thu 3/3/16 64 Control System for ATS Refinement Sat 1/16/16 Thu 3/3/16 65 Launch Vehicle Mon 1/18/16 Thu 3/3/16 66 Final Launch Vehicle Construction Mon 1/18/16 Fri 2/19/16 11/19 11/21 Flight Readiness Review Flight Systems Launch Vehicle E B M E B M E B M E B M E B M E B M E B M E B M E B M E B M August September October November December January February March April May Task Split Milestone Summary Project Summary Inactive Task Inactive Milestone Inactive Summary Manual Task Duration-only Manual Summary Rollup Manual Summary Start-only Finish-only External Tasks External Milestone Deadline Progress Manual Progress Page 3 Project: GC 15 MK 1 Date: Fri 1/15/16
- 95. ID Task Mode Task Name Start Finish 67 Full Scale Recovery System Launch Sat 2/13/16 Sat 2/13/16 68 Full Scale Test Launch Sat 2/20/16 Sat 2/20/16 69 AGSE Mon 1/18/16 Thu 3/3/16 70 Test, and adapt to results for RPDS Mon 1/18/16 Tue 1/26/16 71 Test, and adapt results for RES Mon 1/18/16 Thu 1/21/16 72 Test, and adapt to results for MIS Mon 1/18/16 Thu 1/28/16 73 Full Frame and AGSE Testing Fri 1/29/16 Fri 2/5/16 74 Finalize Construction of Entire AGSE Mon 1/18/16 Thu 3/3/16 75 Operations Mon 1/18/16 Mon 3/14/16 76 Actively searching for funding Mon 1/18/16 Fri 3/11/16 77 FRR Documentation Mon 1/18/16 Mon 3/14/16 78 FRR Submitted Mon 3/14/16 Mon 3/14/16 79 Launch Week Mon 4/11/16 Sun 4/17/16 80 Team ARES Departs to Huntsville for Competition Mon 4/11/16 Sun 4/17/16 81 Post Launch Assessment Review Mon 4/18/16 Fri 4/29/16 82 Post Launch Assessment Documentation Mon 4/18/16 Fri 4/29/16 2/13 Full Scale Recovery System Launch 2/20 Full Scale Test Launch AGSE Operations 3/14 FRR Submitted Launch Week Post Launch Assessment Review E B M E B M E B M E B M E B M E B M E B M E B M E B M E B M August September October November December January February March April May Task Split Milestone Summary Project Summary Inactive Task Inactive Milestone Inactive Summary Manual Task Duration-only Manual Summary Rollup Manual Summary Start-only Finish-only External Tasks External Milestone Deadline Progress Manual Progress Page 4 Project: GC 15 MK 1 Date: Fri 1/15/16
- 96. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 91 of 92 Appendix III: Test Plans
- 97. 2015-2016 Georgia Tech Team ARES Critical Design Review Page 92 of 92 Appendix IV: Control System Paper
- 98. A CREDIBLE AUTOCODING APPLICATION WITHIN A ROCKET AND ITS PAYLOAD Raphael Cohen, Anh-Toan Bui long, Romain Jobredeaux and Eric Feron Georgia Institute of Technology, Atlanta, Georgia Abstract The cost of software engineering and avionics represents more than half of the budget of a safety- critical system like an aircraft or a UAV. The quantity and the complexity of embedded software in such systems is increasing exponentially. Reducing their cost of development is a major objective in the aeronautics and avionics industry. Research in Cyber Physical Systems (CPS) endeavours to contribute to this objective. The traditionnal approach to certify- ing software is to design unit tests to match low level requirements, and integration tests to validate high level requirements. Creating and running these tests require large amounts of time and money. With the recent bloom of companies specialized in UAV and small systems design, there is a need for new methods able to generate reliable codes in large projects easily, quickly, and in a cost efficient manner. Formal methods are a collection of techniques for the mathematical analysis of programs and models, which can assist in the certification of software with respect to FAA and EASA certification guidelines. New approaches to software verification, using formal methods, have been developed in the past few years. In this article, we will focus on a particular method of code generation called the Credible Au- tocoding [1]. Credible Autocoding is a method of certification rooted in model-based design principles and credible compilation. In particular, the tool de- scribed in [2] accepts as an input a Simulink model of a system and then translates it into annotated C code. Simulink is widely used by control engineers, and this technique enables the design to occur at this high level of description, while guarantees are given on the C implementation. C code is generated containing a mathematical proof of desirable properties of the system in annotations. The annotations, included in the C code as comments, describe the behavior of the system in a formal language. Using proper formal analysis tools, the validity of these comments can be assessed [3]. We demonstrate an experimental implementation of this technique on a system. We will present an application on a rocket system and its payload. We used Credible Autocoding for the control command of the rocket, and for filtering the data coming from different sensors including the rocket system and the payload. This research was carried out through a competition organized by NASA, which requires students to build a whole rocket with constraints on several features and performance. The advantage of Credible Autocoding here is the fact that this technique is a great model-based (Simulink) approach that uses formal method to generate documented code and verifies it. We first introduce the different approaches used to generate certifiable code, and make a case for the Credible Autocoding framework in Section 1. Then, in Section 2, we present the project, objectives and restrictions under which this research was carried out. In Section 3, we discuss the work done on the payload carried by the rocket. Sections 4 and 5 introduce the rocket equation, the chosen control strategy and its stability analysis at model level. Finally, Section 6, the main contribution of this paper, describes how to annotate the implementation of a sliding mode controller with its stability proof. We discuss how to extend the credible autocoding tool to support this more sophisticated control strategy. A Case for Credible Autocoding Typical model-based design approaches to the development of safety- critical systems rely on a level A (according to DO 178B classification) certified autocoder. Such autocoders have been developed fol- lowing rigorous software engineering practices, which involve careful documentation of every functionality of the program, as well as a considerable amount of tests and simulation to ensure, as much as tests
- 99. and simulation can, that the autocoder is free of any damageable bug, and that it behaves according to its specification. Based on this absolute trust in the certified autocoder, it is argued that there is no need to spend too much effort on the verification of the generated code, as long as the input model to the autocoder has been thoroughly verified and validated. The Credible Autocoding approach, on the other hand, emphasizes the verifiability of the generated code, rather than that of the autocoder itself. Indeed, using a minimal amount of proof information given at the design level from a domain expert, Credible Au- tocoding proposes to automatically generate not only the code implementing a design, but also a formal documentation describing its semantics. The code, along with the documentation, can then easily be verified using formal analysis tools, as demonstrated in [2]–[4]. The value of this alternative approach is two-fold: first, it seems important that the actual code, to be embedded on the safety-critical system, be subjected to the highest level of scrutiny, rather than the tool that led to its generation. No verifi- cation or validation process is perfect, but one can reasonably expect to obtain higher levels of assurance from taking the analysis as close to the final product as possible. In addition, blind trust in an autocoder may be misplaced, as demonstrated by the following example. GeneAuto [5]–[7] is an open source autocoder developed with the objective of producing embedded code for safety-critical applications. It takes as input a model in Simulink, and can generate code in C or ADA that implements the model. In [2], [4], GeneAuto was extended with automatic generation of formal annotations, in what constituted the first demonstration of feasibility of the Credible Autocod- ing framework. A verification backend was developed to formally verify the annotated code generated by the extended tool [3]. In the process, a bug was discov- ered in the autocoder that had remained undetected for many years. Without entering into its details, the bug was triggered when using a gain block with a matrix gain containing negative entries: the negative sign would be lost in the translation. The authors were alerted to this bug when the translation of a design with a well understood proof of stability was failing the verification of its documentation. Using the line- by-line annotations, the authors were able to pinpoint the origin of this failure, and subsequently identify the bug. More exhaustive testing might have exposed this flaw, but it has been established that testing shows the presence, not the absence of bugs [8]. The formal analysis carried out following the Credible Autocod- ing framework, when it succeeds, proves that the implementation of a design is valid. It can succeed in spite of the autocoder having bugs. While such an outcome is undesirable, it is still acceptable from a verification perspective, since the generated code, and not the autocoder, is a part of the final product. There can be many reasons why the verification backend fails, but being able to pinpoint the location of the failure allows to more efficiently trace the issue back to where it originated. More recent certification documents, like the DO 178C [9] and its addendum (DO 333 [10]), advocate for the use of formal methods in the safety-critical software development process. A formally certified autocoder, along the lines of the one in [11], but at a higher level of translation, would make the first approach significantly more trustworthy, but does not exist, to the authors’ knowledge. The Project The aim of the project is to embed a payload within a rocket. The whole system is built by students. The payload is meant to retrieve atmospheric data. In order to retrieve it after the launch, it is hooked to a parafoil which can be oriented at a predefined GPS position. The rocket is part of a competition orga- nized by NASA. It should reach an apogee of 3000 feet above ground level. To achieve this objective, a system of spoilers called ATS (Apogee Targeting System) is used. Less than 50 milliseconds after the apogee, the parachute of the rocket should deploy in order to deliver the payload at apogee. The flight command and the apogee targeting system are coded with the help of C code. A Sensor Canister The payload has several objectives: • retrieve atmospheric datapoints at different alti- tudes of the drop • filter these values for further data treatment • reach a target point using only a parachute that can be controlled with its brakes
- 100. The Rocket The rocket should carry the payload in order to deliver it at a predefined altitude. The altitude must be set to reach optimal operating conditions for the embedded system and the payload. A high apogee may cause the sensors to deviate more than expected. Therefore, the lift-to-drag ratio of the parachute causes the rocket and the payload to drift farther than the target point or the landing field. The engine has the main influence on the altitude with predefined weight and aerodynamics. The engine is calibrated to reach farther than the expected altitude. As the altitude may be critical for the payload or any experiment conducted in the rocket the ATS is experimented on the rocket. The exact altitude cannot be reached easily. System Architecture The embedded system must be reliable while executing its tasks. It shall: • go to a target from its drop point • be embedded in a rocket as a payload • be reusable several times without modifying its structure • perform with the cheapest components available for making a cheap probe • be certified for avionics regulation • take measurements during the rocket flight and during the drop • send data to the ground during the flight for its retrieval • comply with FAA and FCC regulation • not represent a risk for populations • achieve its mission The development of GPS localization let expand- ing the number of airdrop payload: with its precision, it will be possible to have a target with a 10 meter margin. We can then reunite more easily payloads dropped from one aircraft, deliver packages on the sea. In contrast to specialized platforms (rockets, Ar- iane 5 launcher...), fielded airdrop systems have only a single GPS receiver and no Inertial Measurement Unit. This is desirable to reduce cost and complexity, especially because the GPS receiver does not require any pre-flight calibration. To facilitate prototyping, we use commercially available microcontrollers based on Arduino archi- tecture as well as common sensors for the probe and the avionics embedded in the rocket. The aim is to make the system architecture easier than pulling together electronics components that require more knowledge. The prototype can be then reproduced by anyone, without exploring in depth electronics. This also allows engineering students to handle electronics and test the software they created. Using the Credible Autocoding is in fact devel- oping routines that will be then connected to routines interfacing between the sensors and the software. Tool and Theory Used The system needs filtered values to ensure pre- cision. Filtering Data Kalman filter: In this work, we are going to use different types of filter. A Kalman Filter and a Weiner Filter will be used. Wiener filter: Originally, the Wiener filter takes the whole signal and then filter it for making the best from it. It is widely used in image processing. We export the theory to an unidimensionnal signal. The Wiener filter works with 2 hypothesis: • The true signal and the noise are uncorrelated • The noise frequency is known For a discrete signal, at step k, let sk be the true signal, yk the observed signal and nk the unknown noise. We get then: yk = sk +nk (1) The objective is to get sk with a given yk. The signal sk can be written as : sk = k  i=k N hk mym = N  i=0 hiyk i (2) We define hi as the coefficient minimizing the MSE. The Wiener filter is a filtering based on Mean Square Error (MSE). The error between the original signal and the observed signal must be minimized. This gives N  i=0 hiRy(i j) = Rsy( j), j = 0,1,...,N (3)
- 101. With Rsy(k) the correlation function between original signal sk, and the observed signal yk, and Ry(k) the auto-correlation of signal yk . N is the order of the filter eg. the number of values the filter will take into account. In a matrix form, that gives Equation 4. 2 6 6 6 6 4 Ry(0) Ry(1) ... Ry(N) Ry(1) ... ... ... ... ... ... Ry(1) Ry(N) ... Ry(1) Ry(0) 3 7 7 7 7 5 8 >>>>< >>>>: h0 ... ... hN 9 >>>>= >>>>; = 8 >>>>< >>>>: Rsy(0) ... ... Rsy(N) 9 >>>>= >>>>; (4) For the embedded system, we will calculate offline coefficients hk using Equation 4 with known values. For example, for the altitude, measurement were made at constant pressure/altitude during few seconds. The coefficients are then used as inputs in the software developed. Afterwards, the coefficients can vary according to the situation. Partial Results We made a test of the filtering offline. Mea- surements were made at constant pressure/altitude during few seconds. The measurements must be as close as possible to a constant, the mean value of the measurements. That will give coefficients to apply to the measured value, and the N last values. For this test, the 6 last values were kept, which gives us 6 gain to apply. Figure 1 shows the altitude given by the sensor in blue, and the filtered value in red, versus the iteration. Figure 1. Test at Constant Altitude We take new altitude values at constant pressure with the same sensor to test the Kalman filtering in 1D and Wiener filtering. We filter the values with Wiener’s method and the same coefficients found earlier. This supposes the same noise on the signal. The Figure 2 present the results, the altitude in meters versus time in milliseconds, the blue plot is the original values and the red plot the filtered values. Figure 2. Test at Constant Altitude - Wiener Filter The wiener filtering does not gives enough preci- sion to be embedded: it needs more memory to give a satisfactory precision. The use of this filter is limited by the memory of the embedded system. Results of Kalman filtering are on Figure 3. We take the values the same way as previously. The blue plot represent the original values measured by the sensor and the orange plot represent the filtered value by Kalman filtering, the altitude in meters versus the i-th value. Figure 3. Test at Constant Altitude - Kalman Filter We can use the Kalman filter for every data saved by the system but some parameters as the position in space needs matrices and matrix inversion which is not handled by the autocoding process.
- 102. Rocket Equations and Control In this section we discuss the first step of the rocket study, which consists of deriving the equation and implementing a controller that stabilizes a desired trajectory. The rocket built is part of the project described in section 2, which mission goal includes launching the rocket while carrying a payload and make it reach exactly 3,000 ft at apogee. Equation of the Rocket As a first step, let us derive the equation of the rocket. Let W and D denote the weight and drag of the rocket. Let Ve be the exhaust gas velocity. Then: W+D = d dt (mV) = ma+ ˙mVe. (5) We assume that the direction of the rocket is constant. As a consequence, the angle between the axis pointing towards the nose of the rocket and the vertical axis is constant and equal to a = 5 deg. Then, projecting the previous equation along the vertical axis yields: m¨h = [ ˙mVe D]cos(a) mg, (6) where h is the altitude and Ve the magnitude of Ve. In order to control the altitude of the rocket, we used a system of pins controlled by a motor. The motor can control how much the pins are extended and, therefore, how much drag they create. The total drag force can be written as: D = 1 2 rV2 (CrocketSr +CpinSp), where Crocket and Cpin are the drag coefficients of the rocket’s body and pins, and Sr and Sp the associated surfaces. Introducing the vertical thrust, Tv = ˙mVe cos(a): ¨h = Tv m g cos(a) 2m rV2 (CrocketSr +CpinSp), where V2 = ( ˙h cos(a) )2 = ˙h2 cos(a)2 , Sp = Spo u. Spo corresponds to the exact amount of pin surface needed to reach an altitude of 3000 ft. The nominal trajectory hp is obtained by setting u = 0, and would yield the desired behavior in the absence of disturbance: (i.e., Sp = Spo): ¨hp = Tv m g CrocketSrr 2m ˙hp 2 cos(a) r 2m ˙hp 2 cos(a) CpinSpo. Therefore, defining the state variables x1 and x2 as the vertical position and velocity discrepancy to hp, x1 = Dh = h hp, x2 = ˙Dh = ˙h ˙hp, we obtain the following dynamics: ( ˙x1 = x2, ˙x2 = f(x,t)+g(x,t)u, (7) where f(x,t) = (CrocketSr +CpinSpo)r 2mcos(a) (2 ˙hpx2 +x2 2 ), (8) g(x,t) = rCpin 2mcos(a) ( ˙hp +x2)2 . (9) Control of the Rocket In order to control the system, we chose to imple- ment a Sliding Mode Controller. Following standard practice [12], we define a sliding surface s as: s(x) = lx1 +x2 = ⇥ l 1 ⇤ x. On the surface defined by {x 2 R2|s(x) = 0}, x2 = ˙x1 = lx1, which induces a desired exponential con- vergence of x1 to 0. Parameter l is chosen at design time based on the required speed of convergence. Thus, in order to find a control law that stabilizes the origin we wish to validate the following candidate Lyapunov function: V(x) = 1 2 s2 = 1 2 (lx1 +x2)2 . Its time derivative is given by ˙V(x,t) = s˙s = s(lx2 + ˙x2) = s(lx2 + f(x,t)+g(x,t)u). We choose the following control law: u = ueq +uc, where 8 >>< >>: ueq = 1 g(x,t) (lx2 + f(x,t)), uc = 1 g(x,t) (Ksgn(s)).
- 103. The function sgn is the traditional sign function. Pa- rameter K is chosen at design time and characterizes the speed of convergence to the set {x 2 R2|s(x) = 0}. Then: ˙V(x,t) = Ks·sgn(s). As s·sgn(s) is always nonnegative, we thus have: ˙V(x,t) = Ks·sgn(s) 0. (10) Stability Analysis of the System In this section, we focus on the stability analysis of the discretized system. Indeed, the implementation of the control law will be a zero-order hold version of the continuous controller described in Section 4. In order to make a proof of stability on the system tractable, we discretize its model and carry out a discrete stability analysis. Discretized Model The system is discretized with a sample time of Dt = 0.02 s. A first order Euler discretization yields the following model. xk+1 = xk +Dt x2,k fk +gkuk . (11) The state variables, sliding surface and functions become: xk = x(kDt) ; fk = f(xk,kDt) ; gk = g(xk,kDt) Vk = 1 2 s2 k ; sk = ⇥ l 1 ⇤ xk A Matlab implementation of the controller is given in Figure 4. Our goal is to express an invariant set on the state variables of the rocket, in order to prove Lyapunov stability of the closed loop system. Indeed, equation (10) does not carry over directly in discrete time. The controller accepts as inputs the state x, computes the values of functions f and g and outputs the target area of the pins u. We begin the analysis by searching for a bound on the sliding surface s. ⌥ ⌅ 1 lambda = 0 . 1 ; 2 K = 0 . 5 ; 3 deltat = 0 . 0 2 ; 4 time = 0; 5 x = xo ; 6 s = [lambda 1]⇤x ; 7 while 1 8 x = receive(x , 1 ) ; 9 s = [lambda 1]⇤x ; 10 f = receive(f , time , 2 ) ; 11 g = receive(g , time , 3 ) ; 12 Ueff = 1/g⇤(K⇤ sign (s) ) ; 13 Ueq = 1/g⇤(lambda⇤x2+f) ; 14 U = Ueff + Ueq ; 15 send(U , 1 ) ; 16 time = time + deltat ; 17 end ⌃ ⇧ Figure 4. Matlab Code of the Controller Sliding Surface Stability Analysis In order to find a bound on s, we study the variation of the function V. We show that it is non- increasing. First, expressing sk+1 as a function of sk: sk+1 = ⇥ l 1 ⇤ xk+1, sk+1 = sk +Dt ⇥ l 1 ⇤ x2,k fk +gkuk . Then, recalling that uk = 1 gk (K.sgn(sk)+ fk +lx2,k), yields: sk+1 = sk KDt sgn(sk). (12) Equation (12) enables us to conclude that, in terms of V: Vk+1 Vk = 1 2 (s2 k+1 s2 k) = KDt 2 (KDt 2|sk|) (13) We can see that the sliding surface s is decreasing in norm whenever its norm is greater or equal than KDt 2 = 0.025. Initially, |x1,0| 2 and |x2,0| 1, so |s0| 1.2. We now prove that Is = {|s| c} with c = 1.2 is an inductive invariant set for s. For that, let us assume that |sk| c. Then, two options are possible. • Either |sk| KDt 2 . In that case, the function V (and the norm of s) is non-increasing and thus: |sk+1| c.
- 104. • Or |sk| KDt 2 . Then, using equation (12), |sk+1| KDt 2 +KDt = 3KDt 2 c. In conclusion, the set Is = {|s| c} is indeed an invariant set for the system. An Inductive Invariant for the State Space Using the invariant set for s, we now look for an invariant set for x1 or x2. Indeed, s being a linear combination of x1 and x2, we only need to find a bound on x1 or x2, having already a bound on s. We chose here to find a bound on x1. For that, we will first compute x1,k+1 as a function of x1,k and sk. x1,k+1 = x1,k +Dtx2,k = x1,k +Dt(sk lx1,k), = x1,k(1 lDt)+Dtsk. Now, let us assume that |sk| c and |x1,k| c l . Then, |x1,k+1| (1 lDt) c l +cDt = c l . Thus, the set I = {|s| c,|x1| c l } is an invariant set for the system. Figure 5 depicts I in the (x1,x2) plane. Figure 5. Invariant Set Schema of System in Terms of x1 and s Generalisation to n-th Order Systems In the prospect of applying credible autocod- ing to generic sliding-mode control strategies, it is important to explore potential generalizations of the proposed approach to state-spaces of any dimension. Indeed, this study could be applied to any system of the form: xk+1 = xk +Dt 2 6 6 4 x2,k x3,k ... fk +gkuk 3 7 7 5,xk = 2 6 6 4 x1,k x2,k ... xn,k 3 7 7 5. (14) In that case, the sliding surface is typically defined as: sk = ✓ d dt +l ◆n xk (15) which is also, using the binomial formula: sk = Kxk = ⇥ k1 k2 ... kn ⇤ xk,ki = ✓ n 1 i 1 ◆ li 1 . (16) The surface defined by s = 0, exactly like in di- mension two, has the properties to make the system converge to the origin as a decreasing exponential function. Then, knowing that the system admits a bound on s and converges to the origin on the sliding surface, a similar approach can yield an inductive invariant for the system. Introducing Sliding Mode Semantics in Simulink Diagrams and at the Level of the Code In this section we will discuss how to incorpo- rate the proof of stability and the semantics of the functions f and g into the Simulink model. We will also discuss how to express these semantics at the level of the C code and the general necessity for a library of certified functions for the computation of non-linearities such as the ones involved in the model description. Note that, to our knowledge, this is the first attempt at formal verification of a sliding mode controller. The Verification Process In order to produce a verified code, we proceed in two steps. The first one involves adding all the semantics related to the controller within annotation blocks in the Simulink model of the controller, as presented in [13] and [2], and then generating the C Code containing the proof of stability. The second task consists in writing a C code library containing all the basic functions needed in the calculation of f and g. The added value of this C code library lies in that the functions written in this library are annotated with ACSL contract and the library as a whole can be proven correct using an automated prover. This certified library, combined with the inserted invariant in the annotated C code corresponding to the con- troller, provide clear mathematical evidence of the closed loop stability of the embedded system.
- 105. Figure 6. Global Diagram of the Verification Pro- cess Figure 6 presents a global description of the design, analysis and verification process. As indicated in this figure, the certified C Code library is written manually at this point. The objective, however, is to eventually provide a more complete library of non- linear functions so that the verification process for this type of control law can be automatically done for a larger set of f and g functions. Expressing Semantics with Custom Annotation Blocks in Simulink In order to have the complete semantics of the controller, we need to analyze the functions f and g. The Matlab code of the controller along with the annotations expressing the system stability are given in Figure 8. From the analysis of the function f, we were able to see that the norm of f is less than or equal to 0.2688. For the function g, a bound on a norm will not be useful. The issue with g arises when it approaches zero. As such, we need to ensure that it remains non-zero throughout the execution of the pro- gram. For that reason, we chose to start the controller at t0 = 0.06. Starting the execution of the controller at t0 = 0.06 and having |x1,0| 2, |x2,0| 1 we can then prove that g 0.008. As a consequence we can conclude on a bound for Ueq, Uef f and U. For now, the Credible Autocoding technique described in [2], [13] is only capable of propagating into the C code, Ellipsoid invariants (being very useful for Linear Systems) thanks to Simulink annotation blocks. Here, we need to make sure that the g function will never be equal to zero, which is a different kind of invariant property. On top of that, we also has to change the way to call f and g. In fact, the C code program of the controller has to call the routines get_f and get_g written in the certified library. As a consequence, we need then to create some others simulink annotation blocks in order to generate a annotated C Code similar to the Matlab code presented in figure 8. Figure 7. Annotation Blocks Allowing to Enter F and G Functions Semantics Figure 7 suggests new annotation blocks to de- fine the semantics of non-linear systems in the form of equation (14). ⌥ ⌅ 1 lambda = 0 . 1 ; 2 K = 0 . 1 ; 3 deltat = 0 . 0 2 ; 4 time = 0 . 0 6 ; 5 x = xo ; % |x1| 2 && |x2| 1 6 s = [lambda 1]⇤x ; % |s| 1.2 && |x1| 12 while 1 % |s| 1.2 && |x1| 12 7 x = receive(x , 1 ) ; % |s| 1.2 && |x1| 12 8 f = get_f(x , time) ; % | f| 0.2689 9 g = get_g(x , time) ; % g 0.008 10 Ueff = 1/g⇤(K⇤ sign (s) ) ; % |Uef f| 62.5 11 Ueq = 1/g⇤(lambda⇤x2+f) ; % |Ueq| 63.62 12 U = Ueff + Ueq ; % |U| 126.12 13 send(U , 1 ) ; time = time + deltat ; end %{ f a l s e } ⌃ ⇧ Figure 8. Matlab Implementation of the Controller Containing All the Annotation Verification by Software Prover In order to check that all the proof annotations are correct, we will use a software prover called Frama-C. A C code library of basic functions called
- 106. by get_g and get_f with ACSL annotations has been manually written. Is is presented in Figures 9 and 10. Indeed, in order to be able to verify that the outputs from the f and g functions are truly in the sets specified in section 1, we need some more information about these functions. The purpose of the C Code Library is primarily to provide the control program with the required functions, but also to allow a software prover such as Frama-C to verify their im- plementation. As shown in the figure 6, the software prover will then be able to check the correcteness of the whole system composed of the C code controller generated by the autocoder and the C code library. ⌥ ⌅ # i n c l u d e < s t d i o . h> # i n c l u d e <math . h> /⇤@lemma div : f o r a l l double x , double y ; x >= 0 ==> y > 0 ==> x / y > 0; ⇤/ i n t h_p[709] , v_p [ 7 0 9 ] ; double lambda , K ; /⇤@ a s s i g n s nothing ; @ behavior behav1 : @ assumes a > 0 && b >0; @ ensures r e s u l t >0; @ behavior behav2 : @ assumes 0.92 <= a <= 1.0008; @ assumes 5.25 <= b <= 5 . 2 6 ; @ ensures 0.644946 <= r e s u l t <=1.004216; @ behavior behav3 : @ assumes 0.6 <= a ; @ assumes b ==2; @ ensures 0.36 <= r e s u l t ; @ behavior behav4 : @ assumes 2.4 <= a <= 2 . 4 ; @ assumes b ==2; @ ensures 0 <= r e s u l t <= 5 . 7 6 ; @⇤/ double pow( double a , double b) ; /⇤@ r e q u i r e s 15 <= h <= 1500; @ ensures 0.758 <= r e s u l t <= 1.189481 ; @ a s s i g n s nothing ; @⇤/ double get_rho( double h) ; ⌃ ⇧ Figure 9. ACSL Annotated Header File of the C Code Library (Part 1) Conclusion We presented an approach to extending the cred- ible autocoding framework to a wider category of ⌥ ⌅ /⇤@ r e q u i r e s t >= 0; @ ensures 7.07 <= r e s u l t <= 7 . 6 6 ; @ a s s i g n s nothing ; @⇤/ double get_mass( double t) ; /⇤@ r e q u i r e s t >= 0; @ ensures 0 <= r e s u l t <= 914; @ a s s i g n s nothing ; @⇤/ double get_hp( double t) ; /⇤@ r e q u i r e s t >= 0 . 0 6 ; @ ensures 3 <= r e s u l t <= 143; @ a s s i g n s nothing ; @⇤/ double get_vp( double t) ; /⇤@ r e q u i r e s 0.06 <= t && 12 <= x1 <= 12; @ r e q u i r e s 1.2 <= s <= 1 . 2 ; @ ensures r e s u l t > 0 . 0 0 8 ; @ a s s i g n s nothing ; @⇤/ double get_g( double t , double x1 , double s) ; /⇤@ r e q u i r e s 0.06 <= t && 12 <= x1 <= 12; @ r e q u i r e s 1.2 <= s <= 1 . 2 ; @ ensures 0.2689 <= r e s u l t <= 0.2689; @ a s s i g n s nothing ; @⇤/ double get_f( double t , double x1 , double s) ; ⌃ ⇧ Figure 10. ACSL Annotated Header File of the C Code Library (Part 2) control systems, and its application to the problem of controlling the altitude of a rocket. We described how to look for invariant sets for sliding mode control law with proof, and then how to carry it down to the generated code. So far, the study that has been done was very theoretical. Indeed, the annotations translating the invariant sets were added manually to the code and the C code library was as well manually written and proved by Frama-C. However, this first step paves the way for automation, as the work in [1] paved the way for the automated tool presented in [2]. One future work will be to complete the automated process of propagating invariant sets along the gen- erated C code. The user is only capable of enter sliding mode control semantics into the Simukink model via annotation blocks but these blocks do not generate any annotations so far. This work will involve extending an existing plugin in the GeneAuto
- 107. tool. Other worthwhile avenues of research include carrying down properties of robustness: indeed one useful property of sliding mode controller is their ability to absorb model errors within functions f and g by tuning parameters l and K. Quantifying this property at the level of the code would be particu- larly useful. In addition, the time-varying nature of this system makes it very sensitive to delays, and this sensitivity would deserve some further study. Finally, the annotations provided in this paper assume computations yield their exact real result, whereas floating-point computation effects should be taken into account for a fully sound analysis. References [1] E. Feron, “From Control Systems to Control Soft- ware,” Control Systems, IEEE, vol. 30, no. 6, pp. 50 [2] T. Wang, R. Jobredeaux, H. Herencia-Zapana, P.- L. Garoche, A. Dieumegard, E. Feron, and M. Pantel, “From Design to Implementation: an Automated, Credible Autocoding Chain for Control Systems,” CoRR, vol. abs/1307.2641, 2013. [Online]. Available: http://arxiv.org/abs/1307.2641. [3] R. Jobredeaux, “Formal Verification of Control Software,” PhD thesis, Georgia Institute of Technol- ogy, 2015. [4] T. E. Wang, “Credible Autocoding of Control Software,” PhD thesis, Georgia Institute of Technol- ogy, 2015. [5] N. Izerrouken, X. Thirioux, M. Pantel, and M. Strecker, “Certifying an Automated Code Generator Using Formal Tools : Preliminary Experiments in the GeneAuto Project,” in ERTS, http://www.sia.fr: Société des Ingénieurs de l’Automobile, 2008, (elec- tronic medium). [6] A. Toom, N. Izerrouken, T. Naks, M. Pantel, and O. Ssi-Yan-Kai, “Towards Reliable Code Generation with an Open Tool: Evolutions of the Gene-Auto Toolset,” in ERTS, http://www.sia.fr: Société des In- génieurs de l’Automobile, 2010, (electronic medium). [7] A. Toom, T. Naks, M. Pantel, M. Gandriau, and I. Wati, “Gene-Auto - an Automatic Code Generator for a Safe Subset of Simulink-Stateflow and Scicos,” in ERTS, http://www.sia.fr: Société des Ingénieurs de l’Automobile, 2008, (electronic medium). –71, 2010, ISSN: 1066-033X. DOI: 10.1109/MCS. 2010.938196. [8] J. Buxton and B. Randell, “Software Engineering Techniques,” in Report on a conference sponsored by the NATO Science Committee, 1969. [Online]. Available: http : / / homepages . cs . ncl . ac . uk / brian . randell/NATO/nato1969.PDF. [9] S. C. RTCA, “DO-178C, Software Considerations in Airborne Systems and Equipment Certification,” Special Committee 205 of RTCA, Tech. Rep., 2011. [10] ——, “DO-333 Formal Methods Supplement to DO-178C and DO-278A,” Tech. Rep., Dec. 2011. [11] X. Leroy, “Formal Verification of a Realistic Compiler,” Communications of the ACM, vol. 52, no. 7, pp. 107–115, 2009. [Online]. Available: http : / / gallium.inria.fr/~xleroy/publi/compcert-CACM.pdf. [12] H. Khalil, “Nonlinear Systems,” Prentice Hall, 2003. [13] R. Jobredeaux, T. Wang, and E. Feron, “Au- tocoding Control Software with Proofs I: Annotation Translation,” Digital Avionics Systems Conference (DASC), vol. 10.1109/DASC.2011.6096122, pp. 7C1– 1 –7C1–13, 2011. Acknowledgments This article was prepared thanks to the support of the National Science Foundation under grant 1446758 (SORTIES) and the Army Research Office under MURI award W911NF-11-1-0046. Additionally, we would like to thank the National Aeronautics and Space Administration (NASA) for organizing such project and competition within American universities. The authors would also like to thank Arnaud Dieumegard for his help on the GeneAuto. 34th Digital Avionics Systems Conference September 13–17, 2015