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! Lessons Learned from earlier RockSat-C teams can be found here.

RockSat-C 2017

Carthage College

We learned to pay closer attention to our mass budget while designing the experiment as having to make ballast is something you want to plan for way ahead of time especially when like us half our weight budget was ballast. Trying to get enough ballast and ensuring its secure is a time consuming process and not one you want to be doing on short notice.

We also learned to inspect our circuit boards much more closely after vibrational testing as even one broken resistor can render data unusable. More testing on the circuit components, especially those for power supply, would have improved the results we obtained.

We also learned to notify the TSA of our experiment ahead of going through security because they do not like big metal canisters full of wires and circuitry. One final lesson we learned is to keep a binder of schematics and data sheets for the parts you use throughout the entire design process so component properties can be found quickly and easily and schematics necessary to include in reports can be produced without hassle.

Hobart and William Smith Colleges

Communication is one of the most important aspects of teamwork in a group project with as many moving parts as RockSat. Not only setting up avenues for communication, but also maintaining the use of those networks is imperative. There were times when our group or subsystems would fall out of contact with each other, especially after a presentation, then it would take time to herd everyone back together and get a report on what had been done in that time. Since there was no coordination during these spells that work was done less efficiently than it could have been had several people approached the tasks at hand as a cohesive unit. That lack of efficiency was a major problem as it forced us to devote more time to make up for that loss. Related to this is the need for a clear schedule that can be followed by group members early on in the project, especially for large groups like our own. The lack of a schedule early on made coordination within and between subgroups far more difficult than it needed to be.

During this project we learned the just how important it is to get funding as soon as possible. Finding funding early is powerful because it removes a twofold problem. Firstly, the time and energy spent searching for funding is time and energy that could have been dedicated towards designing the payload, testing vital components, performing research, or any of the myriad of other activities that must be done to ensure for a fully functioning payload. Secondly, as I will later discuss, testing is of great important to a project such as RockSat. However it is impossible to test components if you cannot buy proper components because of the lack of funds. This semester we experienced a minor funding bottleneck wherein we were promised funding by the president’s office, however, the office never gave us the actual funding until several months later. Leaving us in a sort of quagmire, where we had theoretical funding, but could not use any of it. This meant that time that could have been spent elsewhere had to be redirected to trying to find funding that may or may not be needed.

As was mentioned earlier is of great importance to ensure that not only can the payload survive the stresses of launch but also that the payload will function as intended. Calibration of instruments is of vital importance to any project that intends to use any kind of sensor to collect data. Additionally, it is a good idea to test the limits and capabilities of a team's components. It is important to test early and regularly. Testing is one of the best ways to find problems that would have otherwise gone unnoticed. Regular testing allows for the early detection of these problems that would have otherwise piled up unnoticed. Testing early also allows wiggle room, preventing rushing that could lead to even more problems. Calibration testing for the spectroscopy subsystem required a good deal of time, however, due to the fact that testing was started with time left to spare, there were no issues. Finally, research. Research is critical throughout a scientific project. Cutting edge research is released every day; this research provides a good starting point at the beginning of a project. However, the potential of research is not limited to the early stages of a project. New research may offer insight into problems with which student researchers are struggling. New releases on one’s topic also offers a list of experts in the topic of research, some of whom may be open to answer questions and offer insights on the subject of research. For example, at one point, the radiation subsystem had questions about the usage of Kevlar as a radiation shield. The team was able to get into contact with someone who had previously worked with the material who helped them make the decision not to work with Kevlar. Networking within the world of academia offers many such opportunities, all that is needed is the willingness to go out and find them. 

Old Domimion University

Proper payload design would have been achievable with the additional month of time otherwise lost by Monarch-3 due to the funding delay. Unknown unknowns are what ultimately led to the failures in the payload and as-such could not be adequately dealt the use of solid-state storage going forward as well as ensuring the team is staffed with enough people to surge effort when needed. Besides this, Monarch-3 was designed and developed by an Undergrad and a Masters student, with help from a Ph D student. Between classroom/work commitments, Senior projects for the Undergrad, and Thesis for the Masters student, the effort proved greater than 2 could take on alone for total mission success. That being said, some data, dubious though it may be, was acquired allowing Monarch-3 to still accomplish its goal of inspiring follow-on projects.

Oregon Institute of Technology

RockSat-C has left our team with many lessons. We have broken these lessons down into two sections from our two seniors - as they have the most documented perspectives on the highs and lows in the experience. We also felt that two very different perspectives would be more relatable to individual students in the future. This would go beyond our repeated suggestion for a comprehensive and thoroughly utilized checklist. Many teams have a similar list of lessons, so we felt it was best to help the individual team members.

From the electrical engineering lead - Kevin Malstrom: As with any engineering project of this scale, there were important lessons learned, and things that I would do differently if I were starting from scratch. The most significant would be to bring a software specialist into the project early on, to optimize the code needed for the payload. I suspect that this would have allowed for a much higher sampling rate, even with the exact same hardware. Additionally, there were several times that parts of the payload had to be redesigned due to a lack of fundamental research early in the process. Had our team taken the extra time early on to gain a better understanding of the underlying physics of the PV cells we were studying, a number of headaches could have been avoided.

From the team lead - Alexsis Hundley-Kennaday: Future students who intend on being the project manager for an unpaid, student led, intrinsically enriching team, need to be aware of the delays that occur from homework retracting the attention of the team members. In addition, the project manager needs to be aware of the dependence of each member - despite how different their perspectives on the project may be. For example, the mechanical engineer is unable to create brackets to restrain components during flight until the electrical engineer has determined what components will be utilized and what size the items will be. Timelines will have to be adjusted time and time again - your role as the project leader is to redirect and ensure that no matter the issue, you maintain the team’s momentum and enthusiasm in seeing the project through.

In terms of fundraising, researching individual company “foundations” would have relieved this stress, but these were all found too late in our case. This project lead focused on the various academic grants within the state of Oregon. However, when one was not granted to the team - fundraising became a scramble. If it was not for Oregon Tech, and the overwhelming support of the community of the university - we would not have reached the final steps of the program. Therefore, research foundations in advance - do not gamble your luck on a few. Apply for every resource that the team is qualified for. It would be better to turn down money, than to come up short.

I also recommend recruiting more than one electrical engineering student, or in our team’s case - to recruit your second electrical engineering support significantly sooner in the project. The reason that our team did not was due to the program restraints set forth by the electrical engineering department - a senior in electrical engineering was not allowed to collaborate with another electrical engineer as a part of both of their senior projects. This section of the team is responsible for the design for all PCBs, microcontrollers, coding, and overall functionality, which is too much work for one person. The ideal setup would include both a software and an electrical engineer to balance the load more evenly.

Prototyping is also item to focus on. If our team had been prepared earlier in the program - we would have conducted studies on solar cells at another local university’s radiation center. This would have given our team a baseline expectation of what we could have seen throughout the flight - under the assumption that the battery would have been plugged in. This would have been fantastic information to submit to Colorado Space Grant Consortium (COSGC), and even better to showcase to NASA that we have comparable research on the project.

Last, but not least, make sure that your teammates are familiar with one another, and check in on them as an individual throughout the course of the project. Our team became familiar with one-another at the RockOn! Workshop. We built friendships that this project depended upon. The trust we had in one-another’s abilities was essential for our success. However, I never created a fun, group activity for the group. I would highly recommend that you continue to know your team members and do an activity not entirely focused on RockSat-C to keep a healthy stress surrounding the team.

Stevens Institute of Technology

Vibration Isolation: The team would have benefited from having a large supply of spare parts. While at Wallops the Raspberry Pi, that had been used up to that point throughout the whole project, released some smoke from its on-board power supply. With no spare Pi the team had to adjust the code to work with a Beaglebone Black. The most evident problem in the final payload was the mess of wires and electrical tape that resulted from the lateness of the design of the electronics board. The best way to mitigate this problem for future runs of this project would be to build the mechanical side of the project in tandem with the design of the electronics.

One of the largest flaws in the way the canister was set up is the placement of the control accelerometer. This problem developed as a result of plans changing late in the process and cutting corners to fit another accelerometer into a cramped space. The result was the test accelerometers were mounted to a different plate of the canister that the control which is far from ideal. The best way to avoid a problem of this form would have been to design, build and order parts sooner rather than later.

On the same topic of time, a big problem throughout the project was having enough time for the group to accomplish critical tasks. While Jesse Stevenson was the project manager he also was responsible for too much of the rest of project-- always picking up the pieces when someone else dropped them. To avoid this a more dedicated project managerial position in the team would be beneficial to both Jesse Stevenson’s general wellbeing the progress and time management of the whole project.

Under Pressure: When conducting an experiment such as this, it is often unknown what the signals of interest will look like. When building a data acquisition unit, it is especially difficult to build a proper DAQ when there are a great number of unknowns about the signal. In order to
work around this, we could have tried two difficult approaches in order to compensate for our lack of knowledge of the amplitude. The first approach would be to build a DAQ with multiple operational amplifiers, which could take the same signal. Each operational amplifier would have a different gain, and can be either recorded simultaneously or switched between when the DAQ detects a signal that is too low. The second approach would be to use an auto ranging system where the DAQ can control the gain of the amplifier to auto-adjust for a signal of an unknown amplitude. As the data retrieved from this experiment is dependent on the frequency and change in frequency, an auto-ranging system like this is feasible as long as it does not add any significant noise to the system.

Temple University

There were a significant amount of lessons learned throughout this entire design process. It was very important to maintain good communication with everyone and set responsibilities for each team member to complete. Group projects tend to lead to frustration among team members for a variety of reasons, so communicating about any issues and overcoming them is important to stay on the right track.

Another important lesson learned was to always have a backup plan. When dealing with complex designs, there is always a high possibility that something will unexpectedly go wrong. Having a solid plan B in place will eliminate the stress when something fails and avoids hitting a dead end in the design process. It would have been a smart idea to even have a backup plan directly on the payload. Since our radiation sensor failed during the flight, we could have used a second source of radiation collection such as a muon detector. This would have increased our chances of acquiring meaningful x-ray and gamma radiation data.

Patience was key throughout the entire design and building process. Whenever it seemed like we had something figured out, a problem would arise and we would constantly be trying to find solutions to correct the design. Future participants should expect to experience many failures, and do not expect anything to work on the first try. Although it can be extremely frustrating, fixing your mistakes allows you to learn more and gain a deeper understanding of how your system works. Team members should also have patience with one another. It is almost guaranteed that people will get under each other’s skin at times during this process, so having patience with one another is very important.

Lastly, you can never have too many spare parts, especially when it comes to circuit board components. We came across a few situations where we had to order new parts because we did not have any spares which put us behind schedule. Furthermore, when designing PCB boards it is important to check the components, pinouts, and connections numerous times to ensure that they are correct before placing the order. For one of our PCB boards, we did not check it as precisely as we should have and ended up having the wrong pinout for one of the components. As a result, we had to order a whole new PCB which also put us significantly behind schedule.

Overall, there were many things we would have done differently if we knew then what we know now. Nevertheless, it is expected to come across these types of issues when designing an intricate and involved project such as this one. No matter how much advice is given, every team will come across their own problems and mistakes that they must overcome. The best thing to do is just try to prepare for any issues to arise and obtain the knowledge to solve them effectively.

University of Wisconson Sheboygan

We learned to work well as a team by dividing up the work into sections where we each had strengths. We learned to start early and plan for mistakes as we ran low on time by waiting for parts to be ordered/delivered. For instance, we didn’t order our PCB boards early enough and ran into timing issues when we had to redesign our board. In a future mission, we would duplicate all the sensors, PCB, and SD card reader so that if we lost one SD card it wouldn’t mean the loss of all sensor data. We would minimize the glue used when tacking the SD card and other parts, and we would use greater care when removing it. We would practice the process of de-integration with spare parts so it would go smoother and be less risky. We would review our sensor selection earlier before we ordered our PCB board to make sure the sensors are easily incorporated into the software. We would also spend more time planning beforehand to determine what we need before we order. One important thing is to test the PCB’s before attaching the sensors to make sure that both the PCB and the sensor works. There was some trouble programming it and next time we will learn the programming language beforehand and take the classes earlier so we can figure out those programming/command issues before we have the payload ready, giving us more time to resolve issues.

We learned to pay attention to detail and scrutinize everything (especially your own work). You should have a good plan for wire management, use snap together fittings to help mitigate loose connections. Make sure there is a solid team; should include science core, mechanical, electrical hardware, and electrical software teammate. Establish contacts early. Think through integration day, ask yourself “How can the design be made to have an effortless integration?”. Plan ahead just enough to stay on top of things, but not too far to limit creativity. Have easy to use collaboration tools such as Google Drive, email, and Skype for design reviews. Use downtime (winter break) effectively as it can be hard to get in depth into payload when you have work, homework, and classes to attend.

West Virginia Space Flight Design Challenge

Several lessons were learned during preparation for this mission. Software development was done early in the spring semester and then revised a few times, but it is important to test it frequently, similar to the electronics and sensors. Accurate and timely communications between team members are important to avoid misunderstandings that create further delays. Communication platforms such as Slack proved to be a superior change up in the way that the team was able to remain cohesive. Each team found that it was more convenient to utilize its dual functionality to both share files and message one another. A few weeks into it initial implementation, a “team collaboration: channel was added that created breakthrough solutions in that all of the teams were finally able to work together despite the distance of their academic institutions.

Finally, PCB design software should be selected in the fall semester to allow for electrical schematics to be created prior to winter break. PCB designs should be finalized in the late February timeframe and the 1st round of designs should be fabricated by early March. Always plan on doing at least 2 rounds of PCB designs!

After our fallout, it was determined that it would be most sufficient to have a Power Distribution board back up in case vibe testing doesn’t go as planned.

Go to top