After an unsuccessful launch of Hermes II, we have a great opportunity to finish everything that was unfinished at the Hermes II launch, and really put into effect everything this subteam has been working on for the last 3 years. There is not much time until IAP 2020, so we really need to focus our effort on all the deliverables and make sure we prioritize them correctly, as some of them will probably have to be pushed beyond the launch of Hermes III. You can find more about the problems/highlights on the Hermes II flight here.

Subteam objectives on the Hermes III flight

These are ordered by decreasing importance:

1. Telemetry from flight

We want to recover telemetry data from the flight even in the event of a catastrophic failure, similar to the one of Hermes II. For that, we need a reliable radio connection throughout the whole flight.

We still do not know how the sensors behave during flight, so it would be extremely valuable to get detailed sensor data. We need to make sure our data logging is reliable and our data storage is durable, specifically, able to survive a ballistic impact.

2. Parachute deployment

Clearly, we want the AV bay to fire the parachutes. We would also want to put Pyxida in command, but this is yet to be decided

3. Camera video footage

We want to recover video footage from the rocket. Therefore, we need cameras we can turn on with a radio connection and the video of which we can recover in catastrophic scenarios.

How to achieve the objectives

Cameras

At least in my opinion (Luka), this will be one of the first priorities. Cameras we've used so far cannot be reliably turned on and have a whole list of other problems. If I may say luckily, most of the FireFly legacy cameras were destroyed in flight, so we have to buy new ones. Let's take this opportunity to invest in some more serious cameras and do this properly.

I suggest we allocate a whole subsystem to the cameras: the cameras themselves, the power for them and the BBC which is in control of all of them. Our requirements for the cameras subsystem:

• The power for the cameras is separate from any other subsystem, but there is only one power source (with potential redundancy) for the whole cameras subsystem. We can check the power level, which will later be done through a separate power monitoring system.

• We can turn each of the cameras on and off from Pyxida and check their status.
• We can turn the video on or off on each of the cameras, and check the status of the video recording.

For this, we will need:

• New cameras. Research needs to be done in order to find a solution that is not too pricy but also allows for external power and external control of video and turning on/off.
• A new revision of the BBC. The new BBC will have many more responsibilities than revision 1.

Pyxida firmware work

By far the first priority will be fixing the issues we had days before launch when we were detecting liftoff immediately after arming the rocket, without any acceleration. 

/include and /src directories

 Header files need to be put into the include directory for better organization of the codebase. I will do this after all branches have been merged and conflicts resolved before we start working on the code again in the fall.

The build system

Right now, we are building our tests with CMake and our firmware with platform-io. platform-io can be integrated with CMake as well, which would make it easier to compile and upload code without VSCode, and it is much cleaner and has fewer problems that occur in one but not the other.

Testing

Clearly, the issue we had happened due to a lack of integration testing. Had that been done, we would have spotted the error earlier in the coding process (and not a day before launch).

Unit testing

Great work has been done so far, with around 120 unit tests written. However, there are still some components of our code that require testing, unit testing is most effective when all the parts of the code are unit tested.

The issue that occurred was clearly a problem with the integration of components of the code, as all unit tests were still passing. A possible improvement we could make is put down more detailed specifications on how each component should be used with respect to others, and make sure other components don't make different assumptions about this component.

Integration testing (HOOTL)

In my opinion, Hardware Out Of The Loop (HOOTL) testing has been completely neglected this year, which was not a good thing. I do think this was simply because of lack of time, as we have mostly been working towards restructuring code. Nevertheless, this should be of major focus in the fall.

With HOOTL, we want to catch the integration errors we cannot catch with unit testing, which happen when unit tests assume the functionality of a component incorrectly. There is a whole range of possible HOOTL requirements, from a simple executable to a full-blown GUI app. I think we should settle somewhere in the middle, especially in the beginning, and we can add on features later.

The possible requirements, in order of feasibility and importance:

• We are able to compile all of the Pyxida firmware into an executable that can be run on a non-embedded computer. Therefore, we mock the sensor dependencies and step through the code with the GDB debugger. We set out a quick launch expectation check in the main.cpp file. Note: I have made a simple version of that in playground.cpp
• We are able to preset sensor values for different times for a duration of the whole flight, and we log all interactions of the code with sensor objects and other hardware features. We set default responses for them as well. We spit out the log to a file.
• We can feed HOOTL RasAero sim data or a flight log, and the sensor values being fed by the mock sensors are the ones from the log file. The latter will be very important after we obtain data from flight tests.
• We are able to connect the HOOTL radio mocked-out module with MockPyxida so that we can observe the code simultaneously on the ground station.
• We have a GUI that allows us to step through each update loop, and manually set sensor values and observe the radio output, logs, digital pins, communications to BBC, etc.

The last one definitely does not seem feasible in the next 6 months, especially given the length of this wiki page, but surely a good thing to work on/keep in mind.

This is just a rough outline of the different levels of complexity HOOTL could be built to. Certainly, many requirements will change before we actually start working on it. A very important thing to keep in mind is to keep it flexible, such that a moderate update in the firmware code does not completely screw up the whole interface.

Additionally, even if we decide to build a higher-end testing utility, it would probably make sense to keep a few low-end integration tests as a part of the testing executable, together with unit tests, which we run every time there is a change in the firmware code, just to keep track of what got broken. This would also play nicely if we decide to push through with the Continuous Integration (CI), where these tests are run on every push/pull request.

Hardware testing script

The hardware testing script is very important in order to verify the whole board is working - I have personally spent a lot of time trying to figure out which board to leave in LA for the upcoming flight, as I was checking that the flash and radio both work.

Integration testing (HITL)

As Zack pointed out, we should also more formal tests on the hardware itself. The radio and the cameras were both tested with the hardware, but these tests weren't formally written and they were run multiple times, and we could have probably done a better job at formalizing them. We should also just run the code on the hardware more often. This also all depends on how we proceed with HOOTL tests.

Flight testing, radio range tests

As the code is finished, we need to verify it is working also on a real flight, for example, on an L1 or L2 rocket. This is required if we want to put Pyxida in command on Hermes III. Launch tests are also an opportunity to practice our communication during the launch (launch line team and the away team etc).

In addition, we should do some range testing with our radios to make sure we can communicate with the rocket throughout the whole flight even in nominal conditions when we go to an altitude of 30km. If we see that is not possible, we might have to modify the radio hardware we are using. Therefore, these tests need to happen very early so that we can include the necessary changes in a hardware revision if necessary. 

The Kalman filter

The Kalman filter has been the closest to working this semester but still hasn't been finished. Right now, we are still figuring out how exactly to approach it, as Josef has pointed out, we might need to rethink our whole approach. In the future, what we should improve, is communication with the sims subteam to really have the right model of the flight. We should also test it on real data, which we hopefully get from Hermes II, and flight tests otherwise - this just reiterates the importance of flight tests.

However, the Kalman filter is only required if Pyxida is in command - if that's not the case, it is of much lower priority. Despite that, it will be necessary for the future, and it is much more valuable if it runs on board on Hermes III already rather than running it only on its data later.

Ground station improvements

The ground station is pretty well-functional as it is, so most of those are here only if we have people that want to work with Python and we can't really give them firmware/testing tasks.

Hardware test feature

We have repeatedly used the ground station to verify parts of the hardware were functional. This was all done manually and in the same way over and over again. It would be great if we had a feature where we could connect it to a Pyxida ground station board and it would run a series of checks, making sure the hardware is working. It could also verify hardware on a remote flight Pyxida in this same scope - especially make sure the radio communication is working.

In the same scope, we should probably add/implement more commands that can be used in the USB debug state and check different aspects of the hardware.

Advanced plotting

Andrew Reilley mentioned to me it would be pretty neat if we could plot the thrust curve of the rocket directly on the ground station. I suppose there are also other interesting derived plots we could make from the data.

Position of the rocket on a map

This should not be too much of a big deal to do. A quick google search reveals that it's actually not even hard displaying live position of a rocket in Google Earth, so if we have too much time, we could also implement that.

Pyxida hardware improvements

These should be kept to a minimum, as they could trigger software changes and if they have problems, there is not much time to fix them.

Pyxida revision 6 fixes

These fixes have already been made to the PCB documents in Eagle, so there isn't any work that needs to be done.

Component modifications and additions

• Antenna switch
• Piezo footprint
• Flash
• Bluetooth
• SD card

Mechanical modifications

• Conformal coating
• EMI/RFI shielding
• Metal shield on the backside of the board.

Team dynamics

As Zack has mentioned here, the responsibilities of avionics have become quite widespread, and it makes sense to introduce more structure to it.

The areas we need to tackle in the near future:

1. Electronics/hardware:

Designing PCBs, soldering, assembling and testing them.

2. Firmware:

Writing code in C++ for Pyxida (the main flight computer) and CCB (Camera Controller Board), along with unit tests for them.

3. Kalman filter:

The sensor fusion algorithm. If you want to learn more about it, I recommend this video series.

Will involve lots of physics (fluids in particular) and linear algebra.

4. HOOTL:

Hardware Out Of The Loop Testing - a utility for running firmware on a non-embedded machine in a sandbox to verify correctness in simulated scenarios.

5. Groundstation:

Software in Python, used to monitor the rocket in flight. A lot of progress happened last year, so this is not on the critical path.

6. Integration:

In charge of integrating all the pieces of hardware on the rocket, including:

• Pyxida
• Camera board
• COTS altimeters
• Cameras

Also will focus on getting the cameras to work, with the new hardwired camera connections for power and feedback.

7. Radio communication:

 In charge of radio antenna and link testing, working with RF stuff. The most undefined for now, as we have very little RF expertise, os perhaps we would be reaching out to the MIT radio amateur club.

Recruiting

There are many goals on this list, and there are many more we could potentially start working on for the spaceshot, and we won't run out of tasks for a while, so any additional workforce couldn't hurt - it would just give us some extra manhours we could spend on extra features and increased reliability.

The MIT Driverless had a really nice event around finals week in the spring where they invited all course 6 people and had food and presented what they are doing in a chill way - I'm sure we could think of something similar, in addition to Dormspam and activities fair of course.