Content uploaded by Lars Pepermans
Author content
All content in this area was uploaded by Lars Pepermans on Jul 12, 2022
Content may be subject to copyright.
4th Symposium on Space Educational Activities
Barcelona, April 2022
Page 1 of 6
Lessons learnt during the REXUS program on how to manage a student project
Esmée Menting
1
, Thomas Britting
2
, Lars Pepermans2, Bram Koops2
__________________________________________________________________________
Abstract
The paper discusses the lessons learnt during the SPEAR mission that takes part in the 12th
cycle of the Rocket EXperiment for University Students (REXUS) sounding rocket
programme. The mission originated after Delft Aerospace Rocket Engineering (DARE)
designed a supersonic-capable drogue parachute and was unable to test it supersonically on
the existing platforms available to the team. Hence, an experiment was proposed containing
an ejectable test vehicle to deploy the parachute in supersonic conditions.
Throughout the 12th cycle of the REXUS program, the team has faced a number of
challenges. Although during the project cycle the focus lied on resolving technical problems,
in retrospect the logistical, social, and managerial challenges were just as relevant. Despite the
fact that there is ample literature and knowledge available on methods to run commercial
projects, it can be difficult to connect these practices to the workings of a student team.
Therefore, this paper aims to collect and present the experience of the team on how to
navigate challenges specifically related to student projects and their limited resources.
Amongst which: ‘employment’ management (entry, performance and exit of team members),
how to conduct internal and/or external technical reviews, assembly, integration and testing
(AIT) efforts, planning and task management. As the team has gained these insights through
trial and error, the mistakes made will be shared together with how this impacted the progress
of the mission.
Keywords
Project management, mission planning, student project, REXUS.
__________________________________________________________________________
1
Delft Aerospace Rocket Engineering, The Netherlands, esmee.menting@gmail.com
2
Delft Aerospace Rocket Engineering, The Netherlands
4th Symposium on Space Educational Activities
Barcelona, April 2022
Page 2 of 6
1. Introduction
The REXUS/BEXUS program allows students to
perform experiments on top of a sounding rocket or
balloon. [1]. The rocket flies, depending on the
payload mass, to about 80km altitude. The platform
is very suitable for small microgravity and flight test
missions. As the payload opportunity is sponsored by
the program organisers it is offered for free to
universities and students. The Supersonic Parachute
Experiment Aboard REXUS (SPEAR) was designed
to fill the gap between simulations or sub scale testing
and actual flight conditions of parachute recovery
systems. The recovery team of Delft Aerospace
Rocket Engineering (DARE) had access to a large
database of literature and a subsonic wind tunnel, but
no means to test the drogue parachute of Stratos III at
representative flight conditions. SPEAR is a drop
vehicle attached on top of the REXUS payload
module and inside the nose cone. This allows it to be
launched to the upper layers of the atmosphere, where
it will be ejected and follow its own descent
trajectory. SPEAR will deploy a stabilising drag cone
to ensure a stable re-entry after which the drogue is
ejected at supersonic velocities. After the
experimental phase two main parachutes deploy,
allowing the vehicle to land safely. Additionally, a
telemetry system is included to transmit sensor data
and video back.[2]
Figure 1. the SPEAR vehicle mounted on REXUS28
Within the SPEAR project, many challenges were
faced and lessons learnt. Team members gained
experience on the technical and managerial aspects of
a project. Given that this experience consists
primarily of tacit knowledge, it is not easily displayed
or handed over through (technical) project
documentation. This paper aims at describing this
knowledge to aid future student teams and projects.
2. Lessons learnt
2.1. Design
External interfaces and requirements
With an external launch provider such as REXUS,
there is a large external interface that sets
requirements on your project. In this case the
separation system design was primarily driven by
vibration loads, where the REXUS programme
maintained a high qualification level. However, other
interfaces with the rocket, such as electronics and
available volume are important as well. In the early
phase of SPEAR, a larger diameter of the vehicle was
foreseen by the team, which was later reduced when
they were made aware of the REXUS nose cone
ejection system dimensions. It is important to get a
grip on these requirements early on and communicate
frequently with the external parties. Not only because
these requirements will drive your design, but due to
the limited contact moments with external parties
which makes changing interfaces difficult.
Design trade-offs
Within SPEAR, two trade-offs had a major impact on
the full vehicle design. These were the separation
system connecting SPEAR to REXUS and the vehicle
stabilisation. During these trade-offs it was crucial
that quantifiable data was gathered for all concepts,
and to think through the selection criteria. The best
design may only score averagely across all criteria
and is a compromised solution. Quantifiable data,
such as thorough and justifiable mass/volume/cost
estimates, reduces the influence of subjective
judgements, such as emotions.
Within SPEAR, seven concepts for a separations
system were compared. Originally, the clamp band
system was rejected at an early stage due to complex
parts and significant production time. However, in the
end this became the chosen system due to the cost of
another system being underestimated and a
requirement from the REXUS program being
removed. This demonstrates that the trade-off results
can also change throughout the project.
Rapid prototyping
Early on in the project, during the preliminary design
phase, the team started making prototypes using fast
and cost-effective manufacturing methods, of which
especially 3D printing proved to be very useful. By
making these early prototypes, the team got a better
sense of scale of the vehicle and was able to identify
mismatches between interfaces. Additionally, having
a physical prototype of the vehicle helped to make the
necessary design changes to improve the assembly
procedure. It also enabled the team to show a physical
version of the test vehicle to the launch provider
(REXUS organizers) at a much earlier state than if
representative flight hardware had to be produced.
Management of CAD
Within SPEAR, CATIA V5 was the software of
choice for the mechanical design of the vehicle s, due
to availability and previous experience. This version
of the software does not allow for multiple people to
4th Symposium on Space Educational Activities
Barcelona, April 2022
Page 3 of 6
work on the same file at the same time, therefore
GitHub was used to share the files and allow for
version control. Thus, work on the CAD model had
to be properly coordinated and required rigorously
following procedures. During work sessions this
restricted the CAD work to one person.
Using familiar systems
Using a design that a team is already familiar with can
be a great advantage to save on time and resources.
The SPEAR team has based multiple systems on the
experience from previous projects within DARE,
which made it possible to meet the strict deadlines.
For example, the clamp band separation system was
very similar to that of the Stratos III rocket, which the
majority of the SPEAR team was part of. The heritage
reduced the development and testing time
significantly.
Design reviews
Throughout the SPEAR project, multiple design
reviews were held, both internally within DARE and
with external parties, such as REXUS. Although
design reviews with REXUS were mandatory, the
team still opted to have additional design reviews
within DARE. The usefulness of having multiple
design review processes cannot be overstated. During
the internal design reviews, more people were present
with a background that matches the scope of the
project, and that are familiar with the typical
capabilities of DARE. On the other hand, the design
reviews with REXUS proved to be valuable for the
expertise on the vehicle layout, constraints, and
programme. Additionally, the team experienced the
different preliminary design review formats that were
used by DARE and the REXUS organisation and tried
to learn from this difference and implement the best
aspects from both. [3] After organising a design
review and receiving feedback, it is important to
process this feedback in a useful manner. It is advised
to keep track of the feedback given and make these
points actionable through a review sheet; which
contains clear action points including an ID,
responsible members and status. This also enables a
team to update the reviewers with how their feedback
was processed.
Progressively more detailed design
When designing a system, especially one that is as
complex as SPEAR, it is important to design from the
top down. Starting to work out small design details
while the larger subsystem hasn't been set in stone yet
does not work well and can lead to additional work
required or to be redone. Within SPEAR it happened
that the electronics housing was completely designed
down to the last bolts while the interface hadn't been
determined yet. When the connectors changed from
LEMO to a DSUB and the attachment point of the
housing moved, all of the detailed design had to be
redone leading to unnecessary time spent on it.
Within SPEAR the vehicle shape was largely
determined by the available area in the REXUS nose
cone and the flight stability of the vehicle. This in
term lead to significant limitations for the internal
configuration. It is important to gain insights into the
driving requirements as early as possible such that
they can be discussed and set early.
Importance of a small task with high repetition
Within SPEAR a few tasks, which are relatively low
effort, had to be repeated countless times. Some
examples: making many cables/connections between
circuit boards or between the circuit boards and the
peripherals, manually shortening bolts, assembling
the M4 bolts on the pyrotechnic deployment device.
Even if these actions take a small amount of time, the
sheer number of repetitions makes it add up. In
hindsight it would have been worthwhile to look into
a different solution or design to decrease these tasks.
2.2. Production
Manufacturing
During student projects it is common not to have an
experienced manufacturing engineer available. Some
universities offer manufacturing courses or students
rely on external parties. It is a skill that requires
practice. It is recommended that students start early
on in the project with manufacturing courses and keep
their skills up to date. This helps later in the project
when machining is critical. This not only saves time
but also cost due to manufacturing errors.
Design changes throughout production and
integration
Even if your design looks good on paper, in practise
there will be some issues that require redesign. When
building the SPEAR prototype vehicle for the first
time, it became very clear that the small scale of the
vehicle made it difficult to access certain components
with tools. It was required to relocate some
components to facilitate and speed up the assembly
process. These issues can be prevented by setting
requirements on minimum clearance for access, by
test-fitting tools in 3D CAD models, and by writing
thorough assembly procedures prior to
manufacturing. Especially wire clamps in the main
parachute deployment system were located in tight
corners, which made them particularly hard to
assemble and tighten. Another example is the main
parachute canister lids that required multiple design
4th Symposium on Space Educational Activities
Barcelona, April 2022
Page 4 of 6
iterations, such as proper tolerancing of the 3D
printed parts, to guarantee for a successful parachute
deployment.
General production tips – lathing & milling
Prior experience of metal machining allowed the team
to identify design limitations that originate from the
manufacturing capabilities, but nevertheless learnt
some lessons along the way. The support guides for
the separation system had a section of 3.0 mm
diameter and 24 mm length, which proved difficult to
produce due to the part bending away from the cutting
edge. It is also advised to redesign parts to be made
on the simplest machines possible. One of the SPEAR
parts could only be produced with a CNC, and when
neither the machine, nor an operator could be found,
production, and thus assembly and testing was
delayed.
General production tips – parachutes
The SPEAR team already had experience
manufacturing parachutes from previous projects,
however several lessons were learnt and
recommendations can be proposed for other teams.
Initially the SPEAR stabiliser was designed to be a
ballute with a diameter less than 10 cm. Small
parachutes are not only tedious to manufacture, but
they also suffer from two issues: high stiffness and
large relative manufacturing inaccuracies. Wind
tunnel testing proved that the ballute would not be a
feasible stabiliser for SPEAR, hence a solid drag cone
was chosen.
When sewing parachutes that have a frequent and
significant change in layer thickness or number,
which regularly is the case for ribbon parachutes, it is
challenging to set a correct thread tension. It is
recommended to set the correct thread tension for the
highest load-bearing parts (connection points) and
accept a lower performance in other sections.
General production tips – composite parts
There are many different forms of composite
production, varying in complexity and cost. Prepregs
are far easier to work with and will use a lower
amount of epoxy or resin, but they are expensive. Wet
layup works well too, with a bit of practice, for
approximately 25% of the cost. Mass predictions of
composite parts are prone to the use of epoxy, which
can be excessive with students or beginners. Wet
layup will be more sensitive to this, however within
the SPEAR project similar incorrect estimations were
made for prepregs. The outer shell of the vehicle,
budgeted at 300 grams mass, ended up weighing over
800 grams. It is recommended to include a wide
margin on your mass budget for composite parts.
Next to this, specific equipment can be required
during the production of composite parts, especially
when curing in an oven and/or using vacuum
infusion. There are no easy alternatives if any major
infrastructure or tools are missing, so this needs to be
considered during the design phase. For beginners,
consider that your first 2-4 products will not be up to
specs and/or usable. Finally, one has to carefully read
and follow the labels of the used products, keeping
parameters such as drying time in mind.
Include a draft angle on all parts where possible to aid
the release. Within SPEAR the drogue parachute
deployment tube did not allow for a draft angle as a
sabot needed to guide the parachute over a long
stroke. After the mould was used 2-3 times, it could
only be removed by submerging the mould and
product in a liquid nitrogen bath.
2.3. Testing
Frequent testing and assembly
The testing phase of a system is equally important as
the design phase. Commonly, students have the
tendency to rely heavily on calculations and
simulations or assume that these match reality
completely. However, during the SPEAR project, the
importance of testing systems was clearly
demonstrated. For example, the simulations of the
drogue pyrotechnic ejection system matched poorly
with the test data due to the complex nature of the
phenomena. Similarly, the selection of a spring that
was suitable for the ejection of the main parachutes
proved to be a very iterative process, where frequent
testing was necessary. Testing repeatedly also allows
for multiple design iterations to optimise the
functionality of the system. [4]
When testing it is important to be well prepared. Dry
runs should be executed prior to an important test day,
to check presence and correct fit of all parts and test
data acquisition systems. Finally, a back-up day is
advised as there are always unforeseen circumstances
that can lead to postponing a test.
2.4. Management
Member turnover and reliance on individuals
Due to the cycle of the REXUS project and that of
university there will be a change in team members
throughout the project. This means there is a high
turnover rate, peaking at the end of the academic year.
It is crucial to allow continuity within the team such
that the project can remain on schedule. When
recruiting and introducing members into the team
after the start of the cycle it is important to get them
up to speed on the overall project quickly. New
members can work together with experienced
members to improve (tacit) knowledge transfer. It is
4th Symposium on Space Educational Activities
Barcelona, April 2022
Page 5 of 6
also advised to start by giving them discrete, smaller
tasks they can perform in order to get a hands-on
approach early on while getting to know the system.
Each team member has their own skill set in which
they excel. It is often tempting to have members do
what they do best, especially when the project is on a
tight schedule. However, it is not advisable to rely on
a single individual to execute a task that can only be
done by that person. Sharing skills and having
knowledge-redundancy within the team is an absolute
must to prevent skill- or knowledge gaps in case this
critical member leaves the team or is not available.
Documentation can help, however the assembly and
testing phase comprises mostly of tacit knowledge
which is difficult to write down.
Team bonding
Within the SPEAR team there was a strong feeling of
team bonding throughout the project. The social
atmosphere was excellent and the team also enjoyed
off-time together. This meant that everyone got along
with each other on a personal level as well. In every
team and project, there will be stressful periods,
especially before deadlines, tests or the launch.
Friction can increase and it is very beneficial to have
a good personal relationship with your teammates
outside of the work you do on the project.
Team meetings and communication
Throughout the project, weekly team meetings were
held to update all members on the mission progress
and divide new tasks. These team meetings were
purposefully scheduled during lunch time to force a
maximum duration of one hour, which promoted a
fast paced and efficient meeting. Separate work
sessions were scheduled to perform (design) work for
varying systems. However, the work sessions for
mechanical and electrical systems were during
different days of the week. It is recommended to
schedule these at the same time to promote
collocation of the team and regular informal updates
and discussions on the design. The team has a flat
organizational structure, with limited decentralized
decision making [4]. The team leader and chief
engineer reviewed all major decisions in the project,
after these were discussed with the team.
Use of management tools
Within the REXUS project, it is required to include
certain project management tools in the team
documentation, such as a work breakdown structure
(WBS), an organigram, task management, and a
(long-term) planning overview. These are all
incredibly useful tools to manage a team. However,
they are tools that need to be actively used by all of
the team. The WBS and organigram were made to
comply with documentation criteria and were never
revised or used afterwards, whilst this might have
moved some attention to the ground station which
stagnated throughout the project. Task management
and planning were executed in Asana and Instagantt,
two online tools for project planning. Although
useful, it is time-consuming to enter and maintain all
relevant tasks and long-term planning. It is deemed
unfeasible for the team leader or any other single
person to do this alone; it is necessary for the team
members to be actively involved in updating their
systems. The use of these tools by the team members
in SPEAR was very limited; some actively updated
their status but many did not regularly check or use
the tools.
In a few sprints before deadlines there were many
loose tasks that needed to be organised, and for this a
large excel sheet was created. In general, excel sheets
were used regularly to keep track of things in SPEAR:
production progress, design changes, open action
points. These to-do sheets were structured well and
gave a complete overview: ID, system,
changes/actions required, comments, who added the
action point, who is responsible, status (design
updated / produced / assembled / tested / completed).
These sheets worked very well for the team. The
largest downside is that there were many sheets for
different phases of the project, however they were all
collected in one place.
Internal versus external deadlines
The SPEAR project had clear and externally imposed
deadlines by the REXUS project and for scheduled
test campaigns. The team worked vigorously to make
these milestones and complete the required work.
However, it was seen that internal deadlines, with
little to no repercussion when failed, were rarely met.
The short-term planning also did not always include
all required tasks to cumulate to the milestone point.
Therefore, in a short timeframe it was much more
difficult to reach a (steady) high level of progress.
The effort continuously increased to a higher level
before an external deadline. Even though this cyclic
behaviour was noticed, it seemed unattainable to
change it and spread the work load more evenly. This
was also reinforced due to the necessity of rest and/or
more study time after a busy period on the SPEAR
project.
Adapting your planning
Within each project, unexpected road blocks will be
encountered. These can increase the required time or
costs of a project and requires flexibility in the team.
During the SPEAR project numerous items did not
occur as scheduled; a vibration test slot was available
two weeks before the scheduled date, additional test
campaigns were needed for the pyrotechnic mortar,
the design and production of the electronics system
took more time. These issues were generally solved,
but they required additional time commitment from
the team members on short notice. When members
combine the project with a study program, this
4th Symposium on Space Educational Activities
Barcelona, April 2022
Page 6 of 6
flexibility is not evident. The majority of the SPEAR
team members has at some point in time prioritised
the project over their studies to keep the project on
track, which is undesirable. It is unclear whether there
are practical solutions for these problems, but it
indicates advantages of a full-time student team.
Lastly the SPEAR launch campaign was moved over
eight times due to the COVID pandemic and other
reasons, which required exceptional flexibility and
time commitment from team members.
Prioritise
In a complex project it is important to prioritise
features and functions using the slogan "First make it
work, then make it better". During SPEAR it was seen
that too much time was sometimes spent on a nice-to-
have function, when primary functions were not yet
working. It is up to the team leader, planner, and chief
engineer to keep track of progress and prioritise
resource allocation.
Documentation
Documentation in the REXUS/BEXUS project is
done through the Student Experiment Description
(SED). This is a quite large document describing the
entire experiment. However, this SED is not an easy-
to-read document to get people acquainted with the
project. It is strongly recommended to keep writing
short, almost paper like, documents at the end of a
work package that people can pick up and read to get
started with a new phase of the project. Besides these
sections being easier to read, they also serve a
different purpose. Where the SED is mainly used to
detail your experiment to the organisers, these
documents would be used to inform the team. Where
the organisers are more interested in the final design,
safety and external interfaces, the team is more
interested in the design logic and choices and the
internal interfaces.
Use of work packages
The use of work packages with clearly defined goals
can be a pleasant and clear method of working for
students within a bigger team, especially for less
experienced or new members. Within the SPEAR
project, work packages were created that specify
amongst others an objective, due date and constraints.
The use of small work packages can make individual
team members work more independently, although it
takes considerable initial effort for the team lead or
system engineer to create the document.
Workspace resources
Having a workspace or office that is freely
accessible to the team proved immensely useful. The
Dreamhall had many tools and machinery to produce
all mechanical lab, but the other office space was
perhaps more important. It was where the electronics
were soldered, parachutes produced and team
meetings were held. It was also a place for the team
to hang out, had informal meetings and in general
improve the team spirit. Collocation is important for
teams to enable face-to-face communication [5].
Doing a project of this magnitude without such a
dedicated shared space is challenging and will
require more planning of the available workspaces
and reduce social cohesion.
Hand over to next team
Towards the end of the SPEAR project, a new team
within DARE started on a mission called SPEAR II.
Because the SPEAR team was still active on the
project, there was a low threshold for the new team to
reach out for questions. This, in combination with the
extensive documentation of the SPEAR system and
available CAD files, made the knowledge transfer
process successful. Although the final design and
testing of the SPEAR vehicle were well documented
within the SED, the design process itself, including
iterations and trade-offs, was not as elaborate. It is
recommended to also include these sections in order
to prevent reinventing the wheel or repeating
mistakes. Additionally, if possible, performing
system tests or integration together with the new team
are highly effective ways to hand over a project and
transfer knowledge.
3. Conclusion
There are many lessons learnt from the SPEAR
project, which go much further than the technical and
mission goals. These lessons are valuable to the
engineers in this project and their future careers. With
documentation such as this paper it is hoped that these
lessons can also be used by other students to improve
their projects. Furthermore, these lessons learnt show
the importance of student projects to the industry in
its totality.
References
[1] REXUS/BEXUS, EUROLAUNCH. (2018).
REXUS user manual V7.16, retrieved from
http://rexusbexus.net/rexus/rexus-user-manual/
[2] Menting E., et al. "Flight testing of parachute
recovery systems aboard REXUS" SSEA,
Leicester, 2019.
[3] Menting, E., Britting, T., Pepermans, L.
“Evaluation of PDR Formats in Student
Space Projects”, SSEA, Leicester, 2019.
[4] Menting, E. et al. “
[5] Newell S. et al. “Managing Digital
Innovation”, 2019.
[6] Schilling., M.A. “Strategic Management of
Technological Innovation”, 2020.
