# Interplanetary Student Nanospacecraft: Development of the LEO Demonstrator ESTCube-2
## 3 Satellite Development Lessons
### Hardware Development  
The team decided to develop the whole satellite in-house. The decision to develop the whole satellite in-house makes it necessary to develop new skills in an academic environment if not already offered in the local study curricula.  
One of the team's toughest challenges was developing the satellite chassis structure. The team members were given an opportunity to learn engineering skills that were not available in their curricula because the University of Tartu lacks mechanical engineering curricula. To fix the lack of know-how, the recruitment efforts were focused on other local schools, helping us to create a collaboration between academic entities to allow for study credit point transfer.  
Developing deployable structures on the satellite allowed the team to gain the know-how we can reuse in future missions for other purposes, like deployable antennas, deployable heat-sink, or deployable solar panels. A naive approach and lack of know-how of complicated deployable structure design resulted in slow initial development. The team discovered design problems after manufacturing the first satellite chassis and deployable panel structures. As a result, we found plenty of design problems leading to many last-minute redesigns and sub-optimal fixes.  
For electronics hardware design, we found that the rapid iterative development approach helped us accelerate development and find the optimal solution in the shortest time. While developing various system electronics prototypes, the team spend a lot of time trying to make each prototype as good as possible. To avoid wasting money on manufacturing faulty electronics boards, many internal schematics and board reviews were performed, which delayed the progress of electronics development. This led to a lack of actual hardware for software development and tests. Late software tests revealed many hardware issues kept in design for a long time. Due to improper testing procedures or lost documentation of the testing results, the team could fix the hardware problems only by ordering new prototype boards.  
The previously mentioned problems with mechanics and electronics prototype development stemmed from the team's choice to order parts and electronics boards using local manufacturing capabilities. The local manufacturer's expensive services made the team reluctant to use a rapid-prototyping approach. It stemmed from concern about using initial funding too quickly. One of the solutions could be for the academic institutions to invest in prototyping infrastructure, and if performed correctly, could have a return on investment already during the project. Our team solved this problem by finding other funding sources for the project and receiving manufacturing services from abroad to reduce the manufacturing costs per iteration of an electronics prototype or a structural part.  
In 2015, the team chose a dual MCU architecture--STMMicroelectronics STM32F7 series for high-performance tasks and Texas Instruments MSP430 FR series for low-power and low-performance needs. The initial software was developed for STM32F7 MCU. When attempting to port the existing software to MSP430 FR MCU, it revealed that our software architecture was too demanding. This required stopping the development of electronic hardware and software for systems using MSP430 FR MCUs. For these systems, we decided to switch to STMicroelectronics STM32L4 series MCUs with significantly better performance with similar power consumption. Our embedded software team was used to develop software for STM32F7 MCUs, which made us believe that using the same development approach on a similar type MCU would be more efficient.