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!

2013 Teams

Miami University

The biggest lesson I learned after doing this experiment was that nothing will go the way you plan it, and so you have to plan for things to change.  In the beginning of our project there were a lot of problems with teammates and changing who was working on the project, this created a lot of confusion and when half of the team quit after the end of the first semester it was very discouraging and the rest of the team was planning on just giving up. It took a lot of courage to go on but with everything on the line the other two members of the team decided to give it ago.  Another issue that arose was funding, there was a point in the year that we thought we wouldn’t be able to do the mission because we had no money. Thankfully our professor found the right people to talk to about or project and got some money to send all of us to Wallops Island.  The third issue was trying to decide if our experiment was worth sending up to space.  It’s a lot of pressure put on you saying this is one of only a few experiments that get to go up to space, is it worth it? You just have to tell yourself that it is and have confidence in what you are doing. I learned that every experiment sent up is a good one because even if it isn’t for the greater good of the world it is helping you personally learn and excel in learning so it is completely worth it.  In the end it is a very rewarding experience and we are so happy we got to come down to Wallops a second time, and this time with our own experiment. 

Temple University

If our team were to go through the RockSat-C program again, we would do several things completely differently. We would have begun building our payload as soon as possible to identify manufacturing problems, tolerance problems, and to better physically understand our project. Over the past year, we placed a ton of emphasis on perfecting our Solidworks model before we started physically building our model. We thought that this was the proper approach as our model would dictate precisely how we could assemble our model. Unfortunately, this was not the case. The Solidworks model can deceive you and make you believe that your project will be easily built while ignoring the issues that arise when you assemble your actual payload.Timing, scheduling, and execution of tasks occurred very differently than we had originally anticipated. Each group of tasks took far longer than we expected them too in almost every way possible. We have found that accountability helps facilitate the execution of action plans and gives each teammate the ability to focus in on their individual work. Additionally, a rigid schedule with very clearly identified action plans are the most effective means of getting everyone on the same page and organizing tasks.When it comes time to embody your design, selecting individual parts and components can be a difficult task. Technical specification sheets are often ambiguous and difficult to understand properly. Our team found it very useful to contact any and all of the companies we ordered parts from in order to verify that we properly understood the capabilities of their product. We must have called the company we ordered our pump from at least ten times just to make sure we were buying the correct pump. As you can see, for our team finalizing parts and ordering them took much longer than expected.Lastly, small tolerances are difficult to deal with, especially for manufacturing customized components. In a Solidworks model, it is very easy to assume that many manufacturing issues will not be real problems. This is not the case at all. Small tolerances in Solidworks do not show the reality of how impossibly small some parts need to be in order to achieve the design you want. It is necessary to be aware of this, and realize that building a physical model is a completely different endeavor that drawing a Solidworks model.

Eastern Shore Community College

In terms of what to change about the payload we have very little idea. As mentioned before some level of redundancy might prevent a repeat failure. It would have also helped us to have had a connection for external power so when we were not in flight we would not have had to be on batteries. It would have also been helpful to have a means of disabling the payload during some testing. The team and faculty adviser learned a tremendous amount from the process. In our rookie attempt we had grossly underestimated the amount of time needed for preparing and delivering reports. This team was an entirely extra curricular effort and there was no grade encouraging completion to the end. The team members  that followed through to the completion of the project did so after graduating or being within one class of graduating and starting full time employment. The adviser found that he had many willing volunteers for the fun parts and not much help with the parts that weren't so fun. We should have had a more diverse range of skills involved very early in the development. We lacked the skills and resources needed to provide the quality drawings and diagrams needed to define the project before construction began. We were appreciative of the help that we received from Computer Aided Design Students and faculty but they should have been recruited much earlier in the process. The same can be said for mechanical and software design. We would have benefited from dedicated team members just to develop the presentations. 

Mitchell Community College

  • Better Communication
  • Automotive Wire/Staking
  • Have it all working before WFF arrival
  • Heat test components
  • Construct prototypes sooner (first semester)
  • More open invitation to team members from campus community sooner
  • KISS (Keep It Simple Stupid), easier access to components 

New Jersey

  • Make sure the teams bring numerous spare components to WFF. Something will most likely break, and it’s not going to be what you expect...
  • Ensure all connections are vibration resistant, the payload may work great during testing, but when it is subjected to NASA’s 0 to 10G sweep at high frequency, connections may become disconnected internally. They will look fine from the outside, but these disconnections can lead to the payload rebooting, invalid data etc...
  • Expect students to leave the Rock-Sat team throughout the year. Either due to academic or professional commitments, the team ended up half the size by the time of the launch date. 

 Nebraska-Lincoln University

  • Become very familiar with the user guide. If the team had known about the lack of de-spin earlier, the mission would have been drastically different.
  • Prepare for multiple PCB revisions. The PCB will have some mistakes the first time around. Ensure there will be plenty of time to make the necessary revisions.
  • Add test leads to the PCB for quick diagnostics.
  • Prototype early, test often. Design software does a great job of showing the theoretical payload. Often, reality doesn’t agree with the model and prototypes and tests are needed to verify the design. 


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