In order to support future launches, there is a great deal of work that still needs to be done on both firmware and support software for the Pyxida flight computer. Below are summaries of the required future work for each of the current software and hardware projects related to Pyxida.
Firmware
The Pyxida firmware development process has been somewhat hampered due to lack of available hardware to test on. Still, the firmware has made great strides this year and is close to being in a testable state (in fact, tests were planed for the software aboard a number of smaller test rockets/platforms). Currently, we are investigating two options for switching from the Arduino build system (PlatformIO and just writing our own build system through make). These new systems will hopefully help us better manage updating external libraries and give us more freedom in how we edit and work with the code. Within the code itself, the component that most urgently needs testing is the Kalman Filter we are designing to filter our sensor data. The filter has demonstrated output but needs either real data or a real flight for us to verify it works fully.
Ground Station
The software and hardware for the Pyxida ground station are certainly the most neglected project on Avionics. Some work has been done to begin refactoring the communication interface used in the ground station to match the current software. However, the GUI code is fairly slapdash and needs a refactoring and documentation, as well as an effort to unify the scattered library like modules that many people have attempted to write for the ground station in the past. Furthermore, since the main method of communication between the ground station and the Pyxida is via radio, some thought should be put into designing a dedicated radio dongle that can facilitate this communication on a hardware level.
Hardware Out Of The Loop (HOOTL) Environment
This year, work was begun on a compilation environment for the Pyxida firmware that would abstract away the sensor interfaces and other hardware to allow for the compilation and execution of the firmware on a non-embedded computer. In the Winter of 2017, we successfully compiled and ran the firmware with the HOOTL interface - there may be some small changes to HOOTL that need to be made in order to run it against the current firmware version. In addition, a review is needed to determine whether or not the sensor simulation interfaces are accurately translating input data from OpenRocket into realistic sensor outputs. In the future, we would like HOOTL to be integrated into a dispersion analysis package which would allow very good bench marking of the firmware without the need for any hardware.
Pyxida Quality Assurance Package
Work has recently started on a firmware script that can be uploaded to a newly delivered Pyxida to make sure that all of the hardware on the board is functioning correctly. This tool will be a crucial part of future Pyxida certification procedures and will allow Rocket Team members not familiar with Pyxida to determine the health of the Pyxida hardware.
Pyxida Hardware
While the Pyxida revision 5 provided a number of improvements over the previous version, we have discovered a number of hardware problems with the current board design. The currently known problems can be found here: Pyxida Revision 5 Known Errors. In order to speed up the development of the Pyxida PCB and improve its quality, I would suggest first recruiting more students with PCB design skills to the team and putting them on a dedicated task-force for Pyxida. In addition, I would outsourcing the fabrication and assembly of the PCBs to a company in America (previously a Chinese company was used and while their service was cheap, the quality and delivery time was lacking).
In the interest of the future of Avionics on Rocket team, there are several changes to the structure and operation of the subteam that should be made. These are listed below in more detail
More Design Reviews
Future Avionics work needs more input from the rest of the subteams that the Pyxida will be supporting. This is both to check our design and make sure that we are meeting these needs. These are the most urgently needed design reviews:
| Review | Topics |
|---|---|
| Firmware | What parts of the firmware need to be configurable and what options are needed, what build system should be used |
| Hardware | What changes need to be made for Rev 5.1 (or should we go to Rev 6), what sensors need to be changed if any and can we get breakouts to test them, what expansion boards do we need |
| Kalman Filter | Is the model on the current filter correct, who needs to provide information to Avionics so we can feed the model |
Weekly Meetings to Weekly Sprints
Based on performance this year, it seems that it would be a good idea to replace the weekly Avionics meetings with weekly sprints. Specifically this means that instead of holding a weekly meeting for an hour to check in with Avionics members and then expect them to do work on their own time, it would be better to hold a longer (4 to 6 hour) meeting during which members work on their assigned tasks and deliver the update to the team via email. This way, the only thing that each member is responsible for doing on their own time is coming up with goals for the weeks sprint. This allows work to be concentrated and in an environment where maximum support can be provided. It also boosts camaraderie among subteam members.
Use Github for Project Tracking
Github offers a very good interface for tracking progress on both software and related hardware projects. It seems prudent to use this feature in the future to track active tasks on Avionics projects and to record the results of design reviews and project tasks and milestones. This would make project progress visible to the whole team and better help identify roadblocks.