A selection of lessons learned from phase C/D of CubeSat projects of the Fly Your Satellite! programme

Fly Your Satellite!” (FYS) is a recurring programme part of ESA Academy’s portfolio of “hands-on” activities. The programme was established to support University student teams in the development of their own CubeSat missions and aims at transferring knowledge and experience from ESA specialists to students. Selected teams are guided through project reviews and supervised through design consolidation and verification activities, conducted according to ESA professional practice and standards, tailored to fit the scope of university CubeSat projects. As part of the educational goal of the programme, a systematic effort of capturing, discussing and contextualising difficulties, mistakes, and anomalies in general, is carried out. From this effort, the participating students benefit from a unique framework where lessons learned from one project can be transferred to other ones. This exercise is blended with the “regular” transfer of knowledge from the ESA professionals that support the programme and occurs both concurrently (lessons learned from current cycles) and from previous projects (lessons learned from previous cycles). This paper reports a revised and updated collection of lessons learned during phase C/D of the FYS CubeSat projects, in particular the projects now participating in the 2nd cycle (FYS2). At the same time potential changes and mitigating approaches are discussed. Particular focus is given to lessons learned from issues which arose in hardware development activities, as well as from planning and execution of system-level assembly, integration, and verification (AIV) activities. This approach is taken since first-time developers tend to underestimate the number of issues arising when their design is translated from documentation and models into real hardware. In general, it has been observed that many of these issues typically arise from lack of (space) project management experience of the student teams, or from the lack of resources which prevent the application of standard/established methodologies to small satellite/educational project