First, let me introduce myself. My name is Alexis Gorlier; I am a student in aerospace engineering at ESTACA (a French school specializing in mobilities). I'm very invested in an association named ESO (Estaca Space Odyssey), which is part of my school and allows students to work on real space projects. This article will present a project I am working on in my association, and show the issues linked to this project.
I will particularly insist on the electronic system, as I have worked on it these last four months.
The first thing to know about the electronic system of a rocket is what it is used for in students' projects (the issues are not the same on professional rockets as the missions and the laws differ).
In our projects, the electronic system embedded into the rocket has two objectives: retrieve and store data, and eject the parachutes.
During our project, we will simulate the values that would be obtained during the launch and flight of the rocket to predict its behavior.
Of course this project has for constraint that the construction and the takeoff of the rocket are successful on the D-day. Without launch, no data. No data, no parachutes. No parachutes, no rocket. No rocket, no rocket.
Retrieving and storing data permit us to have inputs to study after the flight, see how our parameters evolved, and use this information to improve our next projects.
As for the parachute part, it seems obvious that we need to retrieve the rocket, and to do so we use an electronic system that will release a parachute when the apogee is reached.
These two objectives are very important as they will let us understand what happened during the flight and whether it was a success or not. Therefore, we want our system to work even if some components stop working during the flight.
To do so, we can either have a backup system, use more components than necessary (for example have three barometers instead of one), or even have both, which is the safest way. We call this redundancy.
Another issue of this project is our system's reusability and agility. Indeed, I noticed that a lot of our association projects which have been done a few years before were not documented enough or not reusable in other similar projects.
As our association is changing its objectives and wants to work on more ambitious projects, we need to transmit our knowledge yearly, from the past teams to the new ones, to reduce the time necessary for each project.
Eventually, we will use this time on discovering and testing new technologies that could be interesting to experiment with.
Finally, the last issue we have for the electronic system development is the lack of knowledge from our members in this area. Indeed, our scholar formation is more oriented toward the mechanical field. We are only learning the basics of electronics.
Therefore, it is better to find a system that is not too complex to realize to be sure we will not lose too much time on it.
Description of the rocket and the choices made so far
The rocket ESL-1 (Estaca Space Launcher 1) is meant to be developed in five years. The development started two years ago, so some choices were already made and others are still to be made.
The projects (linked to the electronic part) that are already finished or in good progress are Recovery and Telemetry.
The recovery will use two parachutes, a first one ejected at apogee and a second one ejected after the first at a 1000 m altitude.
Indeed, as the apogee should be at a 32 km altitude, we can't slow down the rocket too much (if the descending speed is too low, the rocket will be carried by the wind and will go too far away from the launchpad).
Therefore, the first parachute will slow down the rocket to a speed of 50 m/s, and the second will slow it down to 10 m/s.
The telemetry has been made and tested. The max range we could test is nearly a 45 km distance between the system and the ground station. We consider our telemetry functional and ready to be used for ESL-1.
We will need to make a few changes depending on the sensors used. The board used for this telemetry is the L073RZ, and our system won't be able to work with another board.
One of the main parts we want to do next year is developing the electronic system. The first thing we need to define is what technology to use in our system according to the constraints imposed by the already finished projects. This is where Luos comes into play.
When I was looking for an internship, one of the Luos maintainers talked to me about the technology he was working on. I then went on Luos website to discover the possibilities offered by this technology and immediately saw that it would fit particularly well with the issues I listed above.
Luos allows to create a network with the possibility of using multiple boards, in which the code is divided into services (parts of code dedicated to one property, for example a service can be used to communicate with a component or manage communication between several components).
The services can communicate, no matter where they are in the network, using messages standardized by Luos.
Moreover, these messages can be easily moved inside the network and reused in another Luos system. Therefore, this property answers our need for agility and reusability as shown below:
It also permits us to easily add redundancy to our system, as we will be able to duplicate a part of our code and adapt some definitions (such as the pins our component is connected to, for example) as illustrated below:
Finally, Luos is quite easy to use because the examples given on the Luos website easily allow to understand how it works, and the Luos's developers are available on Discord to help the community when a problem is encountered.
Considering all the properties I listed above, Luos is an answer to all of this project's issues.
That's why I decided to do my fourth-year internship of four months at Luos to develop a part of my system with the Luos technology, and see if it matches my expectations.
Proof of concept
For this proof of concept, I realized the following system: a barometer connected to a Nucleo L072RB using an SPI protocol and a solenoid connected to an Arduino MKRZero.
The objective of this system is to retrieve the pressure with the barometer, convert the pressure into an altitude, detect apogee, and activate the solenoid releasing the first parachute when apogee is detected. Activating this solenoid will trigger our liberation system and free the parachute to recover our rocket.
I divided my network into three Luos services:
Barometer: Contains an SPI driver and the communication between the barometer and the rest of the system. This service will retrieve the pressure and send it when it is asked to.
Solenoid: This service will activate or deactivate the solenoid when it is asked to.
Application: This service will ask the pressure to the barometer service, transform the pressure into an altitude, detect apogee, and send a message to the solenoid when apogee is detected.
How does it work?
Barometer Service:
SPI driver:
The SPI driver is the most complex part of this system. I won't describe precisely how it works because it would take too long and is not the most interesting part. To put it simply, an SPI driver allows the communication between an initiator and several followers.
The SPI protocol uses four wires: CLK (Clock), MOSI, MISO, and CS (Chip Select).
The CLK permits a common clock between the initiator and followers, synchronizing the writing and reading of bytes. The clock is generated by the initiator and transferred to the followers.
The MOSI is the line where the followers write and the initiator reads.
The MISO is the line where the initiator writes and the followers read.
The CS is the line that permits you to select the follower you want to talk to (one line per follower, initiated to 1 and lowered to 0 to select the follower).
BMP 280:
BMP 280 is the reference of the barometer I use in my system. To retrieve pressure, I need to send the good bytes at the right timing and read and store the response.
The first thing I do is to send initialization bytes. To do so, I first send the address of the register I want to write in, and then I send the bytes containing information such as the precision wanted, the time between two measures, etc.
Then the barometer will continuously measure the pressure (you can also use a mode to measure the pressure intermittently). I obtain the results by reading specific registers and transforming their bytes into pressure.
The last functionality of this service is that when it receives a
GET_CMDmessage, it will return the pressure to the service that sent this message.
Solenoid Service:
This service is very simple. From an electronic point of view, a solenoid is an interrupter.
It only needs to be turned on or off. This service permits to activate or deactivate the solenoid when it receives a state message with the information TRUE (activate) or FALSE (deactivate).
Application Service:
Purpose:
This application is a bridge between the barometer service and the solenoid service. It needs to be able to send and receive messages to/from these two services.
The difference here is that this service does not reply to a message, so it needs to identify the other services first.
- Therefore, this service does a Luos Detection. This functionality allows us to have a map of the system and know what and where the other services are. Then, it stores the ID of these services in variables to be able to communicate with them at any moment.
Communication with the barometer:
The application service sends an auto-update message to the barometer service at the beginning of the program. This permits receiving a message from the barometer every 100 ms (I need this delay in my system, but it can be changed).
Then when it receives a message from the barometer service, it will use the pressure received to determine the altitude and will then use this altitude to determine if the rocket has reached the apogee.
Communication with the solenoid:
- When the application service detects the apogee, it sends a message to the solenoid with the information
TRUEto activate it.
Validation of the POC
I will use Pyluos to test my POC. I made this choice because my system reacts to pressure variations, with pressures between 101,325 Pa (ground pressure) and 850 Pa (high-altitude pressure). These kinds of variations are difficult and expansive to simulate without launching the rocket. This is why I had to find another way to simulate the changes of pressure.
Pyluos allows to send values to the system's services, so replacing the barometer's data with simulated values is possible.
I approximated the pressure variations during a flight and sent the values to my system to see how it reacted. Here is the pressure evolution I am sending:
The initial value is 101,325 Pa, and the minimum value is 800 Pa.
I tried to be as realistic as possible on the first part of this graph (pressure decreasing), but the second part (pressure increasing) is not very realistic as it should take much longer for the rocket to touch the ground. I made this choice because there is no point in being realistic for this part. What I want to test is the reaction of my system.
The second step of this validation is to retrieve the altitude calculated by my system. Here is the graph I obtained:
The maximal value I obtained is 32,586 m. This value seems correct as the pressure is around 850 Pa at 32 km. The last step of this validation is to see when the solenoids are activated.
This will allow us to see if the parachutes are liberated at the right time. To do so, I read the solenoids' state for each pressure/altitude data and store it the first time I detect a TRUE state, meaning that my solenoid had been activated. I then add the four curves obtained (pressure, altitude, solenoid's 1 state, solenoid's 2 state) on the same graph:
We can see that the two solenoids are activated at the right timings (first at 32,000 m and second at 1,000 m). Therefore, our system achieved its objective.
The POC is validated 🎉
Reusability of this program:
- Barometer service:
This service can be reused only with the BMP280 barometer. However, the SPI driver can be used in other applications.
- Solenoid service:
This service can be reused with every interrupter-like component.
- Application service:
This service can be reused for every system that needs to activate an interrupter when a specific altitude is reached. However, it is only usable with a barometer for the moment. It must be adapted with other sensors to be reusable in every electronic rocket system.
What's the future of the project?
As I said in the first part, there are still some years of development left for this project.
If you are interested in this project and want to see how it evolves, you can check our association news on Instagram. There might as well be other publications in the future on that project, you can join the Luos community to discuss about it!
I made a video to present this project as well:
Get started with Luos