News Events

December 15, 2008

We are undergoing final preparations prior to assembly of our flight unit. It's our intention to deliver a functional cube satellite, AggieSat2, by December 31. Delivery will be made to NASA for final flight tests and eventual integration with Space Shuttle Endeavour. Our flight components have arrived and are in storage until later this week when members of AggieSat Lab will begin assembly of the satellite's subsystems. Over the past week several undergraduate students have had the opportunity to practice their soldering technique on spare flight boards. These students will be responsible for assembling the boards for our flight unit beginning later this week. A combination of undergraduate and graduate students will be handling quality assurance for each component and functional tests will be conducted on our flight unit as each component is integrated. Once delivered to NASA, a vibration test and final functional test will be conducted to insure our flight unit will withstand launch aboard the Space Shuttle.

December 11, 2008

In preparation for our mission in May, our software team is continuing their development of our ground support software to expand its capabilities. Currently our software is limited to running on a single computer with one user having control over, and access to, our satellite and its data. We've been extending our software to support two build variations, a central server for data storage and a version that can run on multiple workstations with access to the central server. We'll posses the ability to allow multiple users to control a satellite and access data received from the satellite simultaneously. A summary of these future capabilities is listed below:

Off-site data access

Our ground support software supports two types of builds; a server and a workstation build. Our server handles all data manipulation and storage on a single accessible computer. Users can then use the workstation variant from any computer to access the data from any location as long as that location is within the same network; by a direct connection or VPN.

Multiple users working on a single satellite

Our workstation variant will also support the ability for multiple computers to connect to and access our central server simultaneously. There could be users at several computers, each with access to the same information, each with the ability to command our satellite and view any data returned.

Controller/observer roles

When users access the central server from their workstation, their workstation will be restricted to a particular level of control or access to that server. This will allow users to be assigned a role as either a controller or an observer. An observer will have the ability to view and export any data that has been sent or received from a satellite. Controllers will have the ability to issue commands to a satellite or affect the behavior of the ground support software across a group of users.

December 10, 2008

As part of our Responsive Space Mission initiative, we're developing software that can be reused for current and future satellite missions. Our primary focus within the software team is to continue developing our ground support software, titled Client, which supports flight hardware, and software testing, and our eventual mission in May. Primary benefits of our current software architecture include:

Core service repository

Software capabilities can be accessed through a central repository of services that are available to the entire software package. Each service, when loaded, registers with the core repository. Interaction between services and their users are facilitated by public interfaces that provide fixed capabilities over the lifetime of the service.

Software components encapsulated within modules

Each service or graphical interface is encapsulated with a software module. That module can be loaded programmatically with the modification of a single file. Graphical interfaces can be unloaded without concern for dependencies with other interfaces or with any services it depended on. Additionally, services can be loaded as long as there are no services, or graphical interfaces that are loaded and dependent.

Modules built on MVC design pattern

Though our Client software is built around the central service repository, each module is built on the MVC design pattern. With this pattern, we're able to separate business logic, our services, from the graphical representation of data received from our satellite. Data that is stored and manipulated by our services can then be reused by multiple graphical views or further manipulated by other services with limited additional coding.

December 09, 2008

Our three student lead teams, software, docking, and ground operations have concluded their objectives for the fall semester. Final documentation and presentations were given either the week prior to or the week of our Thanksgiving holiday. Both our Docking and Ground Operations teams presented their design concepts for their systems on November 21st to interested lab members and lab management. Design concepts, and parts lists, for ground operations will feed into purchases being made by our lab over the month of December. These purchases are being made in preparation for assembly and testing of ground support equipment during the spring semester by the ground operations team. Our Docking team finalized several concept designs for a reusable docking system for 3 to 100 kilogram satellites. After a review by lab management, a single concept will be chosen for further development. Further development will include CAD drawings, analysis, and budgets, all of which will be presented to lab members during mid spring. Our software team completed their objective to demonstrate in-house software that allows for multiple users to interact with a single satellite. Our EDU was used for the demonstration and was configured to communicate over its radio to a central ground station server. Software team members were then able to interact with the EDU from any workstation within our lab through our central server. Members from the software team will spend the next month stabilizing the software and removing software defects in preparation for rigorous testing prior to our mission in May.

December 08, 2008

On October 8th students from AggieSat Lab and UT meet with engineers down at Johnson Space Center to complete a fit check. NASA's fit check involves taking both Texas A&M's and UT's Engineering Design Units and placing them together inside a cube satellite launcher. The satellite launcher used, also known as a Space Shuttle Payload Launcher, has already flown in space and will hold both Texas A&M and UT's satellites during the STS-127 mission next year.By conducting a fit check, internal walls within the launcher can be adjusted to insure a tight fit. Therefore, the satellites are not jostled within the launcher during takeoff of the Space Shuttle or during their eventual launch from the payload bay.

A month later, AggieSat Lab used its own SSPL, designed and built by students, to simulate the launch environment on an Engineering Design Unit. Several tests were conducted using structural mock-ups to verify the SSPL was working correctly. Finally, on November 15th, students from UT brought a mock-up of their PARADIGM satellite to our facility at the University Services Building to be integrated with our EDU and SSPL. Upon launch, both satellites were jettisoned from the SSPL, initially matted together prior to separating as a result of their antennae pushing each other apart. Each satellite antennae was spring loaded and depressed when both satellites were matted. After launching, each satellite antennae presses against the opposing satellite, causing both to separate from one another. From those tests, we were able determine what their final velocity would be as they move away from the Shuttle. We were also able to determine their change in velocity after separating from each other as a result of their antennae.