Lessons from Final AIT - CalgaryToSpace/CTS-SAT-1-Wiki GitHub Wiki
Final AIT (Assembly, Integration & Testing) refers to the stage of the satellite in which all the flight hardware is assembled, integrated together, and tested.
This is the final test of all the systems in terms of design & concept, and is the last stage for troubleshooting before everything is epoxied, vibration tested, and ultimately integrated into the rocket to be launched into orbit. This presents unique opportunities for last-minute troubleshooting. In our specific case, we noticed a few things pop up in the process:
-
We had an antenna deployment cable get pinched between the frame wall & the rest of the frame/ADCS. This led to that channel immediately powering off as a preventative measure & an overcurrent fault. What this meant was that a wire was shorting either the ground or the frame.
- We solved this by rerouting the cable such that it didn't come in contact with the frame.
-
After the LEOPS (Launch and Early Operations) procedure, the antenna wouldn't deploy. This was traced back to a capacitor shorting with the frame's endplate. Had this been tested without being connected to the frame, it wouldn't have been detected - there was nothing within the documentation suggesting that this would've occurred. This highlights the importance of:
- Realizing that documentation and reality are different. In our case, it was the orientation of the connector and the capacitor on the antenna that were different, meaning our models were incorrect.
- You need to inspect and document these differences between the models & reality throughout an AIT campaign. This is done preferably by:
- Measuring with detailed photos taken that have a ruler in frame - do this immediately when they are first received and have that saved in a folder on the shared GDrive that people know about. Then compare it to the CAD models by at least 2 people, and correct from there
- Deprioritize simulations & models, especially thermal simulations - they're incredibly hard to do well, especially when the components don't perfectly match their CAD models & such. It is better to empirically test your hardware because of this, and speaks to what more proper project management could look like, with that time having been better spent doing practice CAD projects, starting cable harness models earlier, machine shop training, or real world thermal testing in this case.
- That you need to be methodical and comprehensive in testing - that it was wise to test everything in the frame as if it'd be in orbit and on an individual-component-level, that you need to check if the components respond as expected before & after a test, and that this needs to be done slowly, with rest breaks in between tests.
-
The Deployable Composite Lattice Boom needed its deployment mechanism troubleshooted due to concerns about its length and boom design mount being changed. The DCLB's length was changed by its researcher, and the deployment mechanism was changed after our failure at the vibration testing campaign we were part of at the ESA. These changes were designed to make it harder for the boom to release, which would've let us more easily reach our vibration goals then, but lead to the longer-length boom not being deployable.
- We resolved this by adding a nitinol leaf spring and taking careful measurements on how far we stowed the boom into the mechanism. If this were to fail in-orbit, we've also done some calculations on what spinning the satellite to deploy it might look like, proving that it made for a feasible alternative.
-
While assembling the solar panels onto the frame, we found that it might interfere with both the MPI's measurements & be unable to be flipped to fix it without damaging either the solar panels or the frame. Due to these concerns; one rendering the mission scientifically irrelevant and the other leading to concerns about the vibrational qualities of the satellite, a bit of troubleshooting was done. A few options were considered:
- Addition of washers as spacers under the panels to raise them 1-2mm, which would allow for the solar panels' passives & connectors to not interfere with anything. This had the downsides of vibe testing complications, and wouldn't allow for the panels to be flipped to ground on the MPI side.
- Water jet or laser cut spacer brackets similar to the ones used between our in-house solar panels & the MPI, 1.5mm (1/16") thick. This didn't allow for the flipping of the panels but did have less vibe risk & would be easier than assembling option 1.
- Option 2 for the rear two COTS 2U panels, and a thicker 4.8mm (3/16") material for the front 2 COTS panels near the MPI. This would allow for the solar panel ground to be on the MPI side and lots of room for wires, but would take the longest & would throw off our CoG calculations & calibrations.
These options were considered and then reconsidered as we discovered that our solar panels had the strange property of having the middle of the panels be where the highest & lowest potentials are. This meant that flipping the panels would have no difference on MPI effects, and so we were left worrying about spacing, specifically to fit small surface mount components that weren't in our provided CAD models. This wound up being resolved by going with option 2; 1.5mm (1/16") thick spacer brackets were manufactured to allow for the solar panels' surface components to fit, which would be placed on all sides to minimize changes to the CoG.
To prevent this sort of change occurring so last minute, we've come to realize that we should've asked for better solar panel documentation earlier, especially about surface-mounted components & what the charges are at various points on the panels. This was also partially caused by the centralization of our CAD'ing capacity in a single member, whom was the only one with both experience and hardware powerful enough to manage the whole satellite, but that didn't have access to all the components - the team must have more distributed CAD'ing capacity to prevent such a bottleneck from leading to these last-minute changes, whether that be through training more people and/or running off a cloud-based collaborative CAD software is TBD.
-
Construct the cable harnesses correctly i.e. put the crimps in the correct way. Backup cable harnesses are highly recommended to prevent needing to scramble for more harnesses in case of harness failure, assembly failure, etc.