it took us a long time to get started, but finally after Finn and I wrote our last exam for this semester, we finalized the partslist and got to work. As a short recap: The first step in Project Poseidon is FAR – the Fixed Airframe Rocket. Contrary to what the name suggests, it is actually a teststand and will hopefully never leave the ground. With this pathfinder we want to collect data on the thrustcurve and massflow of a waterrocket. This will help us to evaluate which drymass is feasible and based on that if the Poseidon-Rocket is even possible. Furthermore we want to test out different nozzle-sizes, air to water ratios and more to find a sweet spot for the Poseidon-Rocket.
To record the data during the testruns you actually need two things: Hardware and Software. This article covers mostly the software aspect, but here is a short summary of the hardware we use: Two LoadCells, two LoadCellDrivers, one MicroController and two XBee-Radios. Each LoadCell is connected to a LoadCellDriver. The LoadCellDriver communicates via I2C to our MicroController of choice: A Teensy 4.1. An Xbee-Radio talks to the Teensy via UART and a powerbank powers the whole circuit over the Teensy’s USB-Port. We plan to add another LoadCell and driver for FAR Block 2 and start controlling the main valve in the Block 3 upgrade. For that we need to implement at least one MOSFET and a 12V power delivery system. You can read about why we potentially need more than one MOSFET in this article (coming soon). Hint: maybe we need more than one valve.
The LoadCells are the only things that hold the rocket down in the case of FAR. So all the forces between the rocket and the environment can be measured. And yes, it technically is a rocket even though it never leaves the ground because of the rocket principle.
When you start a new Software-Project I usually begin with asking myself which features this software really needs. In this case I defined them as the following:
- Telemetry: The software should enable the user to control the rocket from a safe distance. To achieve that you actually need two pieces of software: One which runs on the rocket and another one which runs on a Laptop. Both Software-Components need to understand each other, so at least a small communication protocol needs to be defined.
- Recording: As mentioned earlier the data is the most important outcome of these testruns. We therefore need to implement a solid and even better redundant way to store it.
After this Definition of our wishes, we finally can start with the real development of the two Software-Components.
I chose to use Visual Studio Code by Microsoft as my IDE and combined it with the PlatformIO Extension, because I am quite familiar with both of them. Our LoadCellDrivers are based on the popular HX711, so I found a nice Library for them. We preconfigured the XBee-Modules with the XCTU-Application provided by DigiKey, so including the XBee-Modules into our code was as simple as opening a serial port.
In the setup() portion of the code we initialize the Connection to the XBee-Module, mount the SD-Card with the original SD-Library by Arduino, load the latest calibration from the SD-Card for the LoadCells and finally configure them with that data.
In the loop() we read out the latest measurements from the LoadCellDriver, check the Serial connection to the XBee for a new byte and if so, append it to an input string. When we reach a new line character we analyse the input string, which splits into subsections by semicolons. The first subsection represents the command and the following subsections are providing related data for that command.
These commands can for example indicate that the LoadCell-Readouts should be saved to the SD-Card or sent back to the Laptop. If that is the case the program sets a flag and saves or transmits the data periodically in the loop-function. I will discuss the commands regarding calibration later on in this article.
Software for the Laptop
Because I like VS Code so much, I used it as well for the Ground-Station aka my laptop. I combined it in that case with the Python-Extension and used mainly the tkinter and matplotlib library for this software-module. The GUI mainly consists of input options and a plot of the data transmitted by the rocket. A Thread which runs in the backgrounds keeps a copy of the datapoints received in the last 5 seconds. The plot uses that data and tries to update itself as often as possible. When you press a Button, a request is send to the rocket via the XBee-Module connected to the USB-Port of the Laptop. Because the program sets a flag after that, it can keep track if the rocket answered it properly or display an error message when the request times out. All the data I talked about at the beginning of this paragraph is of course received via the XBee-Module as well. Most of the Buttons are self-explaining except for the ones in the calibration sections, so let’s talk about that!
Most LoadCells are measuring force with the piezoresistive effect. It boils down to that the resistance of certain materials change due to mechanical strain which acts on it. When the input voltage to the resistor is constant the output voltage will change when the mechanical strain changes. If you measure the output voltage you can quite accurately calculate the force which is applied to the LoadCell. But for that you need to calibrate the LoadCell because only calibrated data is valuable data. Luckily the relation between load and output voltage is more or less linear, so that shouldn’t be that hard.
When you send the request to “Calibrate Zero!” to the rocket, it will take measurements for 2 seconds and set the average of the as the offset for this LoadCell. The GroundSoftware of course appends the number of the LoadCell which you selected with the dropdown menu in the “Calibration Section” to the request.
The MicroController on the rocket calculates the slope of the line or scale by dividing the average of measurements over the last two seconds by the transmitted weight in grams. The user enters this information into the GUI and it is automatically appended to the request as well. If you are interested in an article that goes into greater detail regarding how LoadCell work, please leave a comment and I am sure that Finn will write one!
I coded this software over the last week and it included many firsts for me. For example I actually never used a Teensy or XBee before. Especially with my new knowledge I have at least 100 ideas about how to improve the code, but in my opinion this software is good enough for FAR. It transmits and records data at around 10 Hz which is plenty for our ambitions as presented in the beginning of this article. It also functions as a stepping stone for me and I will implement all these 100 little ideas into GAP. Because then they are necessary. Of course some software changes are needed for FAR Block upgrades, but they should be minor. So all in all from a software side this was a success. I can’t wait to share our testresults with you.
If you are more of an audiovisual type we prepared a video for you down below. Currently Finn and I are using the time before the next semester starts to hopefully build FAR Block 2 & 3 and test them out. So time for content like this or deep dive videos is limited, expect more in a month or so. We will try our best! That’s really it for today. Thank you for reading and until the next time. Bye!