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!

RockSat-C 2016

Community Colleges of Colorado

Of the many lessons learned, a few stood out in particular. For instance, as there will be complications with order processing and shipping of parts necessary to the payload, one should always order these materials in advance, and in excess. We experienced delays in the arrival of parts and chemicals for DNA testing, a shortage of bacterial DNA which led to 3 empty test tubes being flown, and a broken Geiger tube in preliminary testing before extras were ordered.

There is never enough time in a day to finish a complicated task. We experienced countless setbacks we did not expect throughout the build process. A pesky I2C bug almost caused us to have to completely rewrite the flight computer software, only to find out a week later we wouldn’t even be using I2C as a communication standard for the sensor in question. The final software was not pushed to the flight computer’s IC until around 3 hours prior to the payload leaving for Wallops, and the staking of wires, ballasting of the payload, and full simulation test did not happen until 24 hours prior. Always keep the Pi Rule in mind. Expect that any task you have need to complete will take 3.14 times longer, and perhaps even 3.14 times longer than that to get it right.

Hobart and William Smith Colleges

RockSat-C provided our team with the opportunity not only to work on cutting edge scientific research, but learn along the way about electronics, programing, 3- D printing, machining, team management, and organization. More than that RockSat-C gave us an opportunity to work alongside peers with diverse academic interests and knowledgeable faculty advisors, and gain insight about teamwork, fundraising, and innovative thinking.

Teamwork was an important aspect to the success of our mission. Unlike many other RockSat-C teams, our team consists of physics, chemistry, and architecture majors (no engineers). At first, this seemed like a disadvantage, but this diverse team dynamic only aided our teamwork and collaboration. In order to be successful, it was necessary to understand each individual’s strengths and delegate tasks accordingly. For this particular project, it was crucial to have people to build the payload, research previous studies, write the necessary coding for the Arduino platform, and design the electronic circuits. Each team member was responsible for specific tasks. We learned that it is important to delegate tasks appropriately and collaborate between members to maximize efficiency and produce the best results possible. This skill is important because it will be carried into future projects and careers. Working with a team can be difficult but due to different skills, abilities, and ideas that people have, it is important to be able to collaborate and utilize everyone’s abilities toward a common goal.

Fundraising was surely one of the most challenging aspects of the project for our team. We were delayed for many weeks attempting to find sponsors and research grants for our project. This process helped to make us more focused and committed to the project. We were ultimately funded by the NY Space Grant Consortium, our HWS Student Government, and the HWS Presidents Office as well as KETEK Corp., and Alcoa. We learned how to overcome difficulties in securing research money and how to persuade sponsors to fund our research.

We also learned about innovative thinking, why it is important to constantly ask questions, and the need for a backup plan. The week before launch, we were trying to connect our amplifier signal to our coincidence circuit with no luck. For many days, we used every strategy possible to try and connect the signal between components with no success. As launch time approached we realized that this was not a problem we were going to overcome in time and we resorted to utilizing the backup payload we had been alternatively working on. This shows the importance of thinking outside of the box, asking questions and having a backup plan. We knew throughout the semester that this outcome was a legitimate possibility, and thus constructed a contingency plan. As of date we believe that the solution for our initial payload was an impedance problem and we are currently working on a fix. Another lesson from this experience was that sometimes the simplest answer is the right answer.

RockSat-C was truly an in depth engineering and physics project, but it also provided us with many experiences that have benefited our growth as researchers, leaders, and inquisitive minds. These lessons are invaluable and will reappear often in future projects and ultimately in our careers. We are extremely grateful as a team for this experience and for all of the people involved (Becca, our teammates, our advisors and many other HWS faculty).

Oregon State University and Linn Benton Community College

Always plan for things taking much longer than expected. Make sure you stay on track with the schedule and start designing and prototyping early. You will encounter setbacks. You will need to redesign and order new parts. This takes a long time.

Get spares for every part. We made sure to have spare parts for everything except for these stupid little washers and we had to scramble to find some a few days before flight. Don’t just buy spares of everything, make sure you bring them with you, too.

Ask for help when you need it. If you’re stuck on a problem, don’t wait. Ask questions. Reach out to your fellow teammates, professors, and advisors. They want to help you, but they may not know what you need help with. It can be hard to set your ego aside long enough to admit you’re stuck. That’s ok, these experiments are team projects and everyone gets stuck eventually. It’s better to ask for help than fall behind and miss a deadline.

Trust yourself and your team. Part of working together as a team is knowing when to let go and trust each other. It can be hard to spend so much time on something and trust someone else to protect it. Try to understand they spent a lot of time on it too, and everyone wants the project to be a success.

Be patient with yourself and your team. It takes a year to build an experiment that runs for 10 minutes. Get used to being patient. Be forgiving when mistakes happen We all make mistakes. We all make mistakes. Acknowledge the mistake happened, take steps to avoid future mistakes, and move on. Don’t hold a grudge.

Don’t be afraid to ask questions. Leave your ego at home and get to work. If you see something that looks wrong, or don’t understand something, bring it up. Sometimes we get so wrapped up in our own thoughts that we miss something important, until someone asks about it. Answering questions forces us to think about what we’re saying, and reinforces our understanding of the material. So don’t just ask questions, also answer them!

Above all, have fun. This is one of the most exciting projects you can do, so enjoy every step of the process!

Stevens Institute of Technology

G-Force 3D Printing: Part of the mission requirements for the 3D printing group was to design the components to withstand high forces and great vibration frequency. With that being said, there is definitely room for improvement in the future. One of the biggest lessons learned through this experiment is that you can never be too thorough when preparing for the culmination of such a long project. The printer failed because a wire connection was overlooked and was crimped when it should have been soldered. While the connection was difficult to see and was made from a different project, it should have been considered nonetheless.

In addition, near the final weeks of the project there was a lot of cramming of testing and troubleshooting. While the 3D printing group maintained a steady pace early on when designing the printer, it was difficult to stay ahead of schedule and soon the design phase began to cut into the time allotted for testing. If this experiment is repeated in the year following, more time will be taken early on to jump forward in the design phase and begin testing so that all issues can be worked out well before launch. 

Under Pressure: This project proved to be a tremendous learning experience. Going into this project, the team had little technical expertise that could be easily applied to this project. Many aspects of the design proved to be a learning experience resulting in many payload design changes and technical research both online and with faculty members answering questions. Aside from the tremendous technical skills learned, this project provided a great learning opportunity in regards to team management, deadline creation and execution, and communications skills.

Being unexperienced, the group was not prepared to meet some of the deadlines and was not effective enough at the start of the project or even towards the middle of it. This led to a large quantity of “last minute” work for integration testing and full mission simulation testing. Fortunately, the group worked through this and was able to get the work done on time. In regards to project management, the setup and planning of the project needed to be better thought out and with a far greater understanding of the required technical design and fundamental knowledge necessary to complete the design. Had this been the case, the group could have avoided most problems which stemmed from poor planning or missed deadlines. A sometimes undedicated team also contributed to the problems that the team faced. It is an obvious statement to say that no individual can do everything for the project. If the entire team dedicated more time to the project on a weekly basis, there is no doubt that the many technical difficulties, knowledge gaps and work load would have been distributed better and resolved faster.

University of Delaware

Accurate vibration tests are absolutely essential to ensuring the payload will function correctly on launch day. Should this particular experiment be followed up on, multipurpose port integration should happen much earlier to allow more thorough testing before launch. The key here would be to have everything in place to begin this testing as soon as possible. In this instance, had everything been moving as hoped, integration with the multipurpose port would have occurred as soon as it arrived, rather than having to wait until it was essentially the final line item before launch.

Despite our malfunction here, something our team did well was to have our experiment and a plan for how to do it early on. Without this, the design would be changing too dramatically during testing to thoroughly test anything. This could be an issue for more ambitious follow-ups to this design.

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. Logistics issues such as parts ordering must be streamlined and spares of all components must be available to avoid unnecessary delays. Accurate and timely communications between team members are important to avoid misunderstandings that create further delays. Communication and sharing tools such as online drives, group-editing software (GoogleDocs) and others are useful; however frequent, direct communications (telecons) and coordinated lab work are equally important. Frequent practice of presentations is recommended to establish a consistent flow. 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!

A proper scale adjustment of the accelerometers to accommodate higher accelerations is desirable. This extends to all sensors because their range should accommodate expected and known extreme values of physical conditions during the space flight. Using a different reset rate with the 555 timer could possibly improve sensitivity of the Geiger counter. Uploading programs to the Mini was an issue because the OpenLog used Tx and Rx pins from the board. Whenever possible, general purpose (GPI/O) pins should be used so that Tx and Rx pins are available for program revisions on the Arduino.

In addition to these lessons learned throughout the preparation for launch, some other key lessons were learned after integration and launch. Including fasteners (e.g. nuts/bolts, and standoffs) in the mechanical model to avoid clearance issues during canister integration. Although fasteners were considered in the overall payload canister design and SIS, they were not physically included as parts which still created issues during integration. These issues were workable, but could have been worse and definitely could have been avoided if fastener lengths and sizes were included in the model. Also, the subsystem design requirements did not clearly specify where to place the power connector or microSD cards on the physical board layout. This made it difficult in some cases to connect the power plug or remove microSD cards for data checking. This lesson learned emphasizes the importance of establishing complete and detailed design requirements and levying them on the design team.

Another lesson learned from integration was from the 3D printed enclosures. It was determined that these were unnecessary and only further complicated the integration process. The concept of using the box was clear, but there really should not be any loose components expected in the canister unless a catastrophic failure occurs and this should not be designed for given our class of mission. Furthermore, custom PCBs should really be used instead of proto-board solutions on a rocket launch.

After preliminary data reduction analysis, it was found that the early activation not only provided adequate time for the computers to boot up and start executing the flight software, but it also allowed for a steady-state to be reached for all other experiments prior to the launch making data analysis and fault assessment less complicated. Finally, it was learned that all microSD cards should be either non- permanently glued or taped in place before flight. Staking USB connections into the socket was proven to reliably prevent loss of connection during high vibrations. It is recommended that all removable connections are permanently fixed (solder or epoxy) to the PCB prior to launch unless the need to have a removable connection is justified. 

RockSat-C 2015

Carthage College

Over the course of the RockSat-C program, we learned much about the process for designing and building a sounding rocket payload and working on a high- stakes program as a team. The most important lessons we learned were the importance of proper planning and working together.

The RockSat-C program demands a large time commitment, especially for small teams. Finding time where all team members could come together was essential to the success of our team. We used that time to work on design reviews, build and test our payload, and discuss our progress. As a group, we discussed priorities and timelines for the project and planned and conducted tests that needed multiple people to perform. Team meetings held members accountable for the work they were assigned to do individually, and created a greater sense of camaraderie. We found that we worked best when holding meetings regularly and communicating frequently.

It was also essential to use our time efficiently. As all team members had responsibilities outside of the project, it was often difficult to find large blocks of time to meet and do individual work. Therefore, not wasting time allowed us to progress on schedule. Team and small meetings were most effective when we had a clear goal or project in mind. We also learned that having many people work on a single project simultaneously was not very beneficial. Rather, splitting up to accomplish multiple tasks simultaneously allowed us to make much quicker progress.

The aforementioned lessons hinged greatly on our ability to plan in advance. Planning meetings, priorities, individual tasks, and our overall project was crucial. Especially important was designing a detailed plan for our payload as soon as possible, and giving ourselves ample time for revisions. Early in the program, we had an overall idea of our payload structure, which allowed us to discuss the layout and make changes to it prior to actually building it. We came up with a detailed structural layout, including the electronics layout, prior to the bulk of our construction. This allowed us to later build the payload quickly and proceed to testing. Because we planned out the layout so early, we were able to take into account accessibility to SD cards and our g-switch, which facilitated smooth testing. After constructing the payload, we did not have to make any significant changes to the overall design after construction began.

At several points during our project we encountered difficulties or issues that we didn’t know how to solve, both individually, and as a team. When an individual faced a problem or didn't have enough time to complete a task, it was important that they promptly inform the team as to not hold everyone back or cause the overall project to fall behind. When stumped as a team, we also learned the importance of asking for help of our advisor, other faculty, or the RockSat program head. The most notable example of this was when our latch circuit unexpectedly malfunctioned in a way no one understood. Our first step was to test the component individually, then to try our backups. When all three malfunctioned in the same way, we spoke to several faculty members and got advice from them, eventually culminating in a solution.

Because of the possibility of components, such as the latch circuit, malfunctioning or breaking, we learned to order or manufacture multiples of every piece. This allows rapid repairs to be made in the event of a faulty component. We also brought multiples of each electrical and structural components to Wallops Flight Facility in case something was damaged during vibration testing.

Finally, we learned that all subsystems should have multiple people assigned to them, both to distribute the workload and to ensure testing and construction can continue if a team member is unavailable. We had a teammate fall ill during the year, and because other team members were familiar with and able to continue their work, we did not fall behind. Having foresight and beginning planning early on, and ensuring the team is able to handle unexpected events, was key in our success this year. We learned to plan as a team, as well as individually, in order to balance our workload for RockSat along with our academics. We learned to remain flexible in our plan for the payload, as well as in our individual duties for the project.

Hobart and William Smith Colleges

RockSat-C provided our team with the opportunity not only to work on cutting edge scientific research, but learn along the way about electronics, programing, 3D- printing, machining, team management, and organization. More that that RockSat-C gave us an opportunity to work alongside peers with diverse academic interests and knowledgeable faculty advisors, and gain insight about teamwork, fundraising, and innovative thinking.

Teamwork was an important aspect to the success of our mission. Unlike many other RockSat-C teams, our team consists of physics, chemistry, geoscience, and biology majors (no engineers). At first, this seemed like a disadvantage, but this diverse team dynamic only aided our teamwork and collaboration. In order to be successful, it was necessary to understand each individual’s strengths and delegate tasks accordingly. For this particular project, it was crucial to have people to build the payload, research previous studies, write the necessary coding for the Arduino platform, and design the electronic circuits. Each team member was responsible for specific tasks. We learned that it is important to delegate tasks appropriately and collaborate between members to maximize efficiency and produce the best results possible. This skill is important because it will be carried into future projects and careers. Working with a team can be difficult but due to different skills, abilities, and ideas that people have, it is important to be able to collaborate and utilize everyone’s abilities toward a common goal.

Fundraising was surely one of the most challenging aspects of the project for our team. We were delayed for many weeks attempting to find sponsors and research grants for our project. This process helped to make us more focused and committed to the project. We were ultimately funded by the NY Space Grant Consortium, our HWS Student Government, and the HWS Presidents Office. We learned how to overcome difficulties in securing research money and how to persuade sponsors to fund our research.

We also learned about innovative thinking and why it is important to constantly ask questions. A few days before launch, we were trying to amplify a signal and were using an oscilloscope to monitorize the resulting amplification. For an entire day, we used every strategy possible to try and amplify the signal with no success. After a day of stress and frustration, we realized that the oscilloscope was not properly calibrated and we had in fact been amplifying the signal the entire time. This shows the importance of thinking outside of the box and asking questions. To question the instrument in measurement rather than the circuit was crucial to the success of our solid-state scintillator muon detector. Another lesson from this experience was that sometimes the simplest answer is the right answer.

RockSat-C was truly an in depth engineering and physics project, but it provided us with many experiences that have benefited our growth as researchers, leaders, and inquisitive minds. These lessons are invaluable and will use them often in future projects and ultimately in our careers.

Linn Benton Community College

Always plan for things taking much longer than expected
. Make sure you stay on track with the schedule and start designing and prototyping early.  You will encounter setbacks. You will need to redesign and order new parts. This takes a long time. 

Get spares for every part.  
We made sure to have spare parts for everything except for these stupid little washers and we had to scramble to find some a few days before flight. Don’t just buy spares of everything, make sure you bring them with you, too. 

Use diodes and fuses. Diodes and fuses can help save your electronics from accidental shorts. We blew our safety fuse at least 3 times, including during the shake test a few days before launch. Don’t rely on the fuse to save you, but be grateful when it does anyway. 

Set attainable goals. 
Don’t be afraid to scale down. We were ambitious at first but quickly realized that if we wanted to be successful we needed to make our design simple enough to realize it with the time and resources we had. Make a list of what your experiment MUST do, and what it COULD do, and prioritize appropriately. 

Ask for help when you need it. 
If you’re stuck on a problem, don’t wait. Ask questions. Reach out to your fellow teammates, professors, and advisors. They want to help you, but they may not know what you need help with. It can be hard to set your ego aside long enough to admit you’re stuck. That’s ok, these experiments are team projects and everyone gets stuck eventually. It’s better to ask for help than fall behind and miss a deadline. 

Trust yourself and your team. Part of working together as a team is knowing when to let go and trust each other. It can be hard to spend so much time on something and trust someone else to protect it. Try to understand they spent a lot of time on it too, and everyone wants the project to be a success. 

Be patient with yourself and your team. 
It takes a year to build an experiment that runs for 10 minutes. Get used to being patient.  Be forgiving when mistakes happen
We all make mistakes. We all make mistakes. Acknowledge the mistake happened, take steps to avoid future mistakes, and move on. Don’t hold a grudge. 

Don’t be afraid to ask questions. Leave your ego at home and get to work. If you see something that looks wrong, or don’t understand something, bring it up. Sometimes we get so wrapped up in our own thoughts that we miss something important, until someone asks about it. Answering questions forces us to think about what we’re saying, and reinforces our understanding of the material. So don’t just ask questions, also answer them! 

Above all, have fun. This is one of the most exciting projects you can do, so enjoy every step of the process! 

Mitchell Community College

With this project being a first time experience for most of the team, one of the biggest lessons learned is to assign roles early while simultaneously making them accountable for the role that the individual takes on. This is critical as it sets the tempo for the remainder of the project. The team will then quickly learn of the strengths and weaknesses of every individual involved on the team which guides individuals to fill in positions as necessary to achieve the project goal. 

Another lesson learned is to remain timely on all presentations and interim documents. It is always better to be ahead of schedule than behind schedule. This increases team productivity and prevents potential setbacks that are inevitably going to occur. 

Moving forward, a contingency plan will be needed. No matter how perfect the team envisions an idea it will never be flawless, so always be equipped with alternative routes. Descopes or offramps will be extremely beneficial as they will keep the team on schedule and in route to achieve the overall mission as discussed previously. 

Remaining calm under pressure is another enormous lesson learned. This does not become apparent at the beginning of the project, but when approaching a crucial deadline anxiety and tension often arise. 

Ultimately, remember that hard work and perseverance always pay off in the end. When the rocket launches you will definitely appreciate all of the time and effort that went into building the team's payload. If preventive actions are in set in place and executed effectively the payload launch will be a complete success. This will then transition into an abundance amount of data to complete the project's overall missions and ultimate goal as a program. 

Old Dominion University

The final product of the Monarch-One came about through many trials and tribulations, the single biggest of which was the process by which the team had to follow to order parts. This process involves SWaM vendor (Small, Women, and Minority owned) businesses and is the result of a state mandated law, of which the team was not aware of until December when trying to place initial orders. The lesson learned here is that next time the parts ordering process will begin much sooner, now that the team is fully aware of the procedures that must be followed. This lesson extends beyond the logistic standpoint of a project in that the team must, must, must ask their faculty advisors at the earliest possible time about potential procedural or legal pitfalls that may be encountered during the project. This cannot be stressed enough. The effects of not knowing about this caveat set the team back almost two months and prevented the team from construction and testing of the payload until April. 

Another lesson learned was that the RockSat-C User Guide becomes the team’s best form of guidance during times when an answer is needed but the RockSat manager is not immediately available for feedback. The User Guide is packed with information – all of which is useful for the team, especially a first year team. The earlier a team (or maybe just the team leader/manager) becomes familiar with the User Guide, the better. 

Our team organization was such that each major portion of the project had a different representative who was in charge of their respective area. The team was successful, but having a secondary or backup person for each subject matter expert would be ideal for a team next year. No matter how prepared a team may think they are events happen throughout the year that makes ideal project development incredibly difficult. From illnesses to class workload to family responsibilities to job offers, no one person should be responsible for one area of the project. All facets of the project need to have a primary and secondary person dedicated to the follow-through of expected milestones for their portion. Our method of assigning areas of responsibility worked well, but could have been better due to the fact that some members of the team were relied upon much more than others. Shared responsibility may also lead to better accountability within the team, which will almost assuredly lead to a more successful mission by enhancing teamwork and fostering productivity. 

Quite possibly the single thing that helped the team the most was having members who attended the RockOn workshop the previous year. The RockOn team learned how to build, test, and integrate a payload for a sounding rocket launch in three days but the lessons learned in those three days helped throughout the entire year with RockSat-C. None of these lessons were more important than testing the payload during every single stage of the assembly process. Verification of functionality of the payload and operational effectiveness during each developmental step ensured the team would more readily catch an error sooner rather than later. This was extremely important given the delay in beginning the build and test process due to having to wait to order parts and material. Simply stated, the odds of the Old Dominion University payload team success would have been greatly reduced had they not had members who attended the RockOn workshop prior to initiating a RockSat-C flight experiment. 

Oregon State University

When assembling a payload, create a checklist of everything that needs to be accomplished. This will prove to be very helpful, as we would have. In both the shake test and the actual test, we had a battery be misplaced and fall out of the payload. Along with a checklist, this might have been avoided. 

Furthemore, if this payload were to be flown again, our team would have devised a more efficient secondary containment system. Our team found that our overall design was too large, while the small design we utilized was inconvenient for dismantling the system post flight. 

This experience taught us to plan in advance. Moreover, it’s important to take advantage of resources even if it means going out of your comfort zone to seek the help needed. Even though the official acceptance for the program is around January, it’s never too early to order materials and start working on subsystems. Be patient and estimate extra time when ordering items or getting makrolon plates manufactured. It’s very likely that parts won’t come when you expect it. There’s always the probability of delays or longer turnaround times than expected. It’s also important to order enough extra components, to be able to remake a component, and keep them in house. You never know when components will fail or blow up. This will also prevent incidences where you’re trying to order components but find out a store ran out of them. Always list out components you’ll need so that there is a list to go through when ordering the components. It also helps keep track of what has and hasn’t been ordered. 

Setting weekly goals help keep the team in check and on track for further progress. It’s also important to start testing subsystems at least two months prior to June because it allows revisions to be made without having to worry about time constraints. Similar to any group project, communication is key. It lets the other group members know what’s going on, such as if one area of the project isn’t progressing much. 

Additionally, we learned that this project would have been less time consuming had we recruited more people in the areas of expertise needed. It would have been helpful to have another Electrical Engineer or Computer Science team member as well as one or two Mechanical Engineers. Having a Mechanical Engineer on the team or someone that was proficient with Solidworks would have been really helpful. Fortunately Ariel Stroh from the LBCC team helped us with the Solidworks components. Nevertheless, our team has been through a drastic, yet rewarding, learning curve on this journey. 

Stevens Institute of Technology

The bacteria control group should have been stored with the rest of the bacteria while at Wallops. The control group’s results are somewhat suspect as the control was kept in a dramatically different environment than the other samples for about two weeks. These huge environmental differences are an issue. In that vein, the team should have made earlier contact with subject matter experts when doing initial design for the payload and experiment. If the team had had more conferencing with graduate students and professors early on, it would have made the results of the experiments that much more reliable.  

An over reliance upon certain team members was also dangerous for this group. Between Fall and Spring semester, the group’s member list underwent a dramatic change and nearly all teammates needed to be replaced due to the initial team’s waning interest. A more aggressive recruitment plan is already in place for next year.

Temple University

The biggest lesson from this experience is how to work in a team on a long project. It doesn’t seem to be a big factor at first but if you do not have team skills it will work against you during a long arduous project. 

West Virginia Rocketeers

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. Logistics issues such as parts ordering must be streamlined and spares of all components must be available to avoid unnecessary delays. Accurate and timely communications between team members are important to avoid misunderstandings and delays. Communications tools such as online drives, group-editing software (GoogleDocs) and others are useful, however frequent, direct communications, and coordinated lab work are equally important. Frequent practice of presentations is recommended. Finally, 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! 

In addition to these lessons learned throughout the preparation for launch, some other key lessons were learned after integration and launch. Including fasteners nuts/bolts, and standoffs) in the mechanical model to avoid clearance issues during canister integration. There were several instances where holes were experiments were placed to close together making it much more difficult to tighten the fasteners with standard tools. Also, the subsystem design requirements were not heavily enforced or properly communicated to each team member and in some instances off-ramps/de-scopes were taken to waive some of these requirements and not properly communicated to the rest of the team. This lesson learned emphasizes the importance of establishing design requirements and levying them on the design team. This also outlines the importance of strong communication and expression of concern amongst all team members involved. 

After preliminary data reduction analysis, it was found that the early activation not only provided adequate time for the computers to boot up and start executing the flight software, but it also allowed for a steady-state to be reached for all other experiments prior to the launch making data analysis and fault assessment less complicated. Finally, it was learned that USB connections should be glued or soldered into the USB socket to prevent loss of connection during high vibrations. In fact, all removable connections should be permanently fixed (solder or epoxy) to the PCB prior to launch unless the need to have a removable connection is justified. 

RockSat-C 2014

Carthage College

After working on this project for almost a year, it is difficult to not see much come of it this year. This teaches an important lesson, however. This taught us to accept failure, and move past it to identify how we could improve the experiment if we were to attempt it again. 

The biggest lesson that we learned was how to go about making a project of this scale. We learned how to go through a project from the ground up, We worked together to delegate work properly and meet deadlines. We learned how to write a funding proposal, and even how to speak in front of a large audience. 

Something that we can now do better would be our method of data collecting. We could design our experiment such that we avoid distortion due to curved glass. Now that we know a bit more about what goes into the data analysis process, we could design our experiment to make everything easier and more standardized.

Howard University

Participating in the RockSat-C program was a great learning experience. We learned from the design process, the building process, and we especially learned from our failures: 

  • It helps to have specific materials for certain payload designs. If you change the materials, you may also have to make serious changes to the design to accommodate for the different materials. Our first design specifically involved a thicker tubing that, in reality, did not integrate well with the rest of our design. The thinner tubing that we ultimately ended up using was more compatible.
  • Familiarize yourself with different tools, materials and mechanical parts in order to have a clearer idea of what is needed for a desired function. We ended up making several unnecessary purchases from Home Depot because we were trying out different materials to see which worked well in our design. Had we been more familiar with the inventory at Home Depot, Swagelok, and McMaster, we would have saved a lot of money and time. 
  • Perform system integration tests as early as possible to allow for time to correct design faults and hardware malfunctions. The system in our payload was not fully integrated until shortly before launch week. we found ourselves rushing and unable to acquire materials due to the little time we had left.
  • It is important to have roles clearly defined for each team member and a implementation plan that the team could follow. To ensure that every team member is given a chance to contribute to the development of the payload, tasks for everyone should be clearly defined with regular meetings held to confirm that everyone is on the same page. There were times when certain tasks were unnecessarily repeated while others were left unfinished due to misunderstandings. Through clear correspondences and task assignments, our work would've been completed more efficiently.

Mitchell Community College

Project BaDSTAR was a huge learning experience for every member of the team. The largest lesson learned was to always expect things to not go as planned. There were many instances in which this happened to the team during the course of this project. From one member not being able to make it to a team meeting to having the payload being far away from meeting its weight requirement to having voltage on the canister, things happened. This is where the second lesson which was learning the value of having contingency plans. 

As the team members learned to expect things to not go as planned, they learned to develop more than one solution for every possible problem. As far as lessons learned relating directly to the RockSat-C program, the team would advise future participants to always keep the RockSat-C Check-In Procedure in consideration from beginning to end. The team learned this the hard way when it came to Check-In Procedure at Wallops. The biggest problem that the team was having was voltage on the canister. This taught the team a valuable lesson of knowing the electrical component thoroughly such as knowing where ground planes are located on electrical components is important. It is also important to have the schematics of the payload on hand at all time in case a problem like the voltage of the canister occurs. 

Based on the performance of the image-capturing system, the team learned that it is essential to do thorough research on electrical components that a team is considering to use for its payload. The performance of a subsystem or even the whole payload depends on the quality purpose of the components. By doing thorough research on electrical components can let a team know whether the electrical component is suitable for the mission. 

Some of the other lessons learned were more related to the team ourselves. Communication is a very essential part of any team. Without it, a team can quickly fall apart. There were times where people seemingly went missing without word about why or what they may have accomplished. This left the remaining members in a state of limbo until the missing party returned. 

From a different aspect of communication, don’t be afraid to throw out an idea that may seem rather radical. Other members may have been thinking the same thing and it may even lead to a new solution. Also, don’t be afraid to ask for help or admit that you can’t do what you agreed to do. Sometimes people bite off more than they can chew and there should be nothing wrong with admitting this. Someone may be able to help out which is better than toughing through it and not getting it done in time. This causes people to have to scramble and rush to get it done which can lead to errors and tension that could’ve been avoided. 

Speaking of tension, another lesson learned here would be that it can be easy to forget that other team members are also people. Now that sounds bad, and we never had a major problem with this, but other teams very well may have and it is essential to keep in mind. If a teammate loses their cool and snaps at another person, don’t be afraid to apologize. Tempers can flare because this can be a frustrating project, certainly in the days approaching the launch if things aren’t going well. 

Lastly, some general lessons we learned about various aspects of the project. Make sure everything and anything is documented. Nothing beats having a well laid out and organized handbook of data sheets and schematics. This ties into communication and general organization. Always have backup parts and tools. It is better to take too much and not needed it than to not have enough and scramble for ideas last minute.

West Virginia University

The WVU and WVWC teams flew a number of experiments that focused on space science of the ionosphere, atmosphere, and magnetic field, and on radio communications with a ground station. Members of the student team traveled to Wallops for the final integration and to attend the launch, run a ground station, and work on data analysis. The majority of the experiments were successful and the problems in the flight code were in most cases overcome in the data analysis stage. 

Data from the flight dynamics experiments (FD and SPACE), as well as the ground telemetry provided by Wallops, were very useful in the data analysis. The plasma probe was based on a design that was flown in 2012, and also tested in the plasma lab and in the ionosphere. The airglow experiment was an elegant application of atomic physics theory in the upper atmosphere of the Earth. The space-to-ground communications experiment was not successful so a future team may plan to test it more carefully and improve its design. 

Students involved in the mission focused on one or more experiments and worked several sensors, electronics, and/or software programs. The learning curve was steep, but we managed to stay on top of it. This was a demanding payload for both the science and the organizational goals, and most of the comprehensive-success criteria were met.

RockSat-C 2013

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. 

RockSat-C 2012

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

RockSat-C 2011

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