Lessons Learned From RockSats Past

The following teams have provided lessons learned from their RockSat-C experience.  Lessons learned are a critical component of every design to continue improving the design and to avoid losing time/money/resources by making mistakes that have already been made.  This list also includes a small amount of "Best Practices". After identifying shortcomings, multiple teams have suggestions of how to counteract these things. Learn from the teams before you, because they did a lot of learning!


2012 Teams

Northwest Nazarene University

There are many things to take away from a big project and there are always things learned. Out of the things NNU students learned, the main lesson was the transition between design and reality. A Solidworks drawing does not show really how much a machine can do. Anything can be done on Solidworks but not everything can be milled to those specifications, nor are there screws of every size. The strength of Aluminum for the walls of our boxes was enough but there was not a good way to know how thin those walls could be and how accurately something that small could be machined.

Another thing learned was that team integration went smoothly because drawings had been shared and standards from the RockOn workshop  in terms of standoff sizes were used.

Good communication was a necessity and being available for that communication helps.

If another payload was to be flown, space on that payload would not be wasted. A large amount of ballast was used and although the quality of application for the few experiments was high there could have and should have been a high quantity of experiments. It was wasteful to not do so.

Another lesson learned was that testing is vital! A last minute code change caused an error that limited our amount of data. This small code change should have been tested more before the flight. Do not let a simple mistake affect your data!

Mitchell Community College

- Better Communication

Throughout the project, our team noticed the need for solid communication between each subset of personnel. There is, however, a difference between noticing an issue and mitigating it. Clear and thorough communication is at the core of this project and, as such, it should be given careful consideration. Google groups has been a valuable asset and keeps everyone informed as to exactly what is going on all the time, provided that all team members use it as the main line for communication.

- Automotive Wire/Staking

Wiring and staking was a constant problem with this payload. Using thicker shielded wire will eliminate inductive interference that is inherent in a payload of this type. Staking will prevent pulls and tugs causing a loss of contact between wires. This was probably the issue that doomed our payload not to take any data at all. A hard lesson learned and one that will not be repeated.

- Have it all working before WFF arrival

This one is what we tried to accomplish but didn’t. We thought we had a working payload done but kept making last minute changes for various reasons due to multiple problems that arose. The last 10% of the project taking 90% of the project time came into play here. A problem we foresaw but did not mitigate.

- Heat test components

The circuit boards were exposed for a full day before launch to 90+  degree F temperatures. Inside the payload the temperature was probably much hotter. The sensing board acted as if heat scrambled the program before launch.  Heat testing components is a must before launch next year.

- Construct prototypes sooner (first semester)

While the first semester of the project is mainly reviewing designs, Mitchell believes that more prototypes need to be made first semester to allow more test and evaluation. Being a two year college, simulations performed by higher level institutions cannot be performed at Mitchell. Constructing more prototypes earlier will mitigate this issue.

- More open invitation to team members from campus community sooner

Our team started as part of a class physics project, after the fall semester, we invited a few others from around the college to come in and be part of the team. A majority of these new recruits proved to be an invaluable asset to the project. On future projects, a more open invitation will be issued to a broader audience. This invitation will be extended earlier in the project and allow members to become more integrated into the team at an earlier time.



- KISS (Keep It Simple, Stupid), easier access to components

During debug, access to components was difficult. Design for simplicity and testing at a later date is a must for proper evaluation of the payload integrity. Access to components and systems must be made easier to ensure quicker changes can be made, if needed


2011 Teams

Drexel University

Project: Implementing a despun platform during the ascent of a sounding rocket

1) Create a cross-functional team to meet the needs of the project. The Drexel team was formed before a mission statement was defined. However, it was quickly learned that the team had an excess of Mechanical Engineers and not enough Electrical/Computer Engineers to evenly distribute the work.

2) Set expectations for weekly time commitment. Explicitly stating the expectations for hours spent per week help team members gauge how much work they should be putting in and ensures that all members are involved.

3) Early in the process, create as many constraints as possible. This dramatically narrows down the design space and helps reduce the “blank page” effect.

4) Tell everyone about your experiment (create a 30 second commercial). Whenever contacting a company about a product for the payload make sure they know what the product is for and that it is student run. Many companies are willing to sell their products at a reduced price or even donate them for student use (Drexel’s team experienced this first hand).

5) Use Dropbox (or any shared folder that can be mapped to a drive/folder) for SolidWorks files. This allows for multiple people to look at the same model and creates a version that isn’t subject to the whims of a hard drive.

6) Integrate hardware as early as possible. Hardware will never work the first time and often requires a redesign or modification, which usually necessitates access to a store, shipping, or a machine shop, all of which are only open during normal business hours.

7) Factor shipping costs into the budget. When ordering many components, shipping costs can become very expensive, especially if something needs to be rushed.

8) If using metal platforms, make sure nothing has the possibility of shorting to each other. Use electrical tape for components to rest on so they don’t short through the platform.


Colorado State University

Project: Optical Mass Gauging System For Use in Microgravity Environments

For future teams working on this project it is recommended that the team begin working on electronics as soon as possible to provide ample time to address the inevitable problems that will arise during integration. Because flash memory is necessary to achieve the ruggedness required for launch, it is suggested that programming purchasing of the components be made a priority due to the high complexity of their integration. It is also advised that printed circuit boards be used to eliminate issues with the compression and subsequent breaking of wires.

RocketSat related meetings and requirements are time consuming and can impede the progress of the payload development. Therefore time should be managed accordingly. It is beneficial to designate one team member to keep track of the due dates and required presentations that the team must complete on a regular basis.


Harding University

Project: Measure the absorption spectrum of Earth’s atmosphere as a function of altitude using a mini-spectrometer

The first and most important lesson that we learned is communication between team members is key for success. This is especially important when each team member comes from different fields of study. In order to solve problems quickly, it was important to learn how to communicate the problems so that everyone on the team could help come up with a solution. Often, the person that would come up with the solution was not the person that knew the most about that subject. That is why it is also important for the members of the team to know each other’s progress, so that as soon as a problem arises everyone can get together to solve it.

Another lesson learned was to be able to adapt and work with what you’ve got. The analog to digital converter we were using in our experiment was too slow to read in spectra fast enough. This caused a lot of saturation due to the amount of light being absorbed in the time it took to capture a spectrum. We did not have the time or money to order a faster converter or make our own. Instead we decided to use a cosine adapter that we had on hand to reduce the amount of light entering the spectrometer. This worked well and made for a quick and easy solution.

A crucial lesson we learned is to always allow more than enough time for testing. There are always going to be unforeseen problems that arise when subsystems are integrated and tested for the first time. Not only are there usually multiple problems, but they are the problems that will take the most time to work out because it involves communication between all of the team members and conceptual understanding of each subsystem.

Finally, it is extremely important to not only design everything before it is made, but to test things as they are being made. When things are made without some kind of design, there is always going to be a flaw in the final product, which will create problems down the road that will take longer to solve than if a design had been made in the first place. The same goes for testing during the building process. If no testing is done until the final product is assembled, there will be a substantial amount of problems to fix.

Go to top