mirror of
https://codeberg.org/portospaceteam/E-42.git
synced 2024-11-01 14:29:44 +00:00
180 lines
8.7 KiB
Markdown
180 lines
8.7 KiB
Markdown
|
SOFTWARE ENGINEERING DEPARTMENT
|
||
|
|
||
|
SITUATION REPORT 1
|
||
|
|
||
|
Rocket Logging System Architecture
|
||
|
|
||
|
Luís Jesus
|
||
|
|
||
|
August, 2022
|
||
|
|
||
|
Summary
|
||
|
=======
|
||
|
|
||
|
The main purpose of this report is to develop the first plan of our
|
||
|
rocket's logging system in order to get a more detailed plan of the next
|
||
|
tasks that will be done. In this document, we will be talking about our
|
||
|
overall electronic architecture and some of the possible approaches that
|
||
|
we may want to implement in order to get the data from the sensors
|
||
|
chosen by the Electrical Engineering Department.
|
||
|
|
||
|
Data will be received in two different ways: it will be stored in
|
||
|
comma-separated values (CSV) format in a persistent storage device, such
|
||
|
as a microSD card, and we'll also need to implement a "real-time\"
|
||
|
transmission of the data using both radio connection (main real-time
|
||
|
system) and 4G/5G broadband network. The viability of this last one is
|
||
|
still under analysis of the Electrical Engineering Team.
|
||
|
|
||
|
Velocity, GPS, altitude, accelerometer, gyroscope and magnetometer are
|
||
|
the parameters that we want to save and transmit.
|
||
|
|
||
|
Introduction
|
||
|
============
|
||
|
|
||
|
The Electrical Engineering Department was responsible for selecting the
|
||
|
most suitable components. We will be working with an ESP32 main board.
|
||
|
This microcontroller is not very energy demanding and has a quite good
|
||
|
configuration for the purpose we want it to.
|
||
|
|
||
|
Along with this board, we'll have five main modules/sensors that will be
|
||
|
responsible for retrieving information to the ESP32. We will be using a
|
||
|
BMP280 barometer that communicates either through SPI or I2C, a BNO055
|
||
|
IMU module communicating through I2C that integrates an accelerometer, a
|
||
|
gyroscope and a magnetometer, the Ultimate GPS Breakout v3, that will
|
||
|
also be responsible for velocity tracking and connects via UART and a
|
||
|
LoRa or XBee antenna module (yet to be decided).
|
||
|
|
||
|
Backup Logging System (microSD card)
|
||
|
====================================
|
||
|
|
||
|
As mentioned in the introduction, we are planning to implement a
|
||
|
real-time transmission of the data acquired from the sensors. However,
|
||
|
radio waves are very prone to be reflected by the soil, at the
|
||
|
beggining, and there may be some interference caused by other factors
|
||
|
that we may not be able to predict very accurately.
|
||
|
|
||
|
Considering this, we firstly have to think about a more reliable Logging
|
||
|
System that is going to be able to save all the important information in
|
||
|
a persistent storage device, so we can recover the data that was lost as
|
||
|
soon as we have the rocket "in hands\" again.
|
||
|
|
||
|
The most reasonable way to do this is by implementing a microSD Card
|
||
|
Module in the circuit; it usually communicates via SPI communication
|
||
|
protocol (the electronic implementation of this module was not
|
||
|
considered by the Electrical Engineering Team; they must confirm if it
|
||
|
can be made considering all the other modules that will be connected).
|
||
|
|
||
|
ESP32 allows us to use Arduino IDE(C/C++ languages). After some quick
|
||
|
research, I noticed that we will have to use SD.h and SPI.h libraries in
|
||
|
order to write to the SD card. Beyond these, all the sensors/modules we
|
||
|
will be using have their own libraries: Adafruit\_BMP280.h,
|
||
|
Adafruit\_BNO055.h and Adafruit\_GPS.h.
|
||
|
|
||
|
It's not very easy to start trying those implementations without having
|
||
|
the components. I think it is important to begin by a very simple
|
||
|
Arduino IDE code (without considering possible optimizations) to
|
||
|
analyse, for example, how much time it takes to get the data from all
|
||
|
the sensors and write the string in the .csv file. The first approach
|
||
|
must be a loop that reads sensors' values at a fixed rate, builds a
|
||
|
(C-)string and writes it on the file. The frequency of reporting is
|
||
|
actually quite variable in different projects and I couldn't find a
|
||
|
consensus, but it would be interesting if we started testing at a rate
|
||
|
of 10 logs per second (100ms). The most amount of data per second, the
|
||
|
better, however, we have to pay attention to some details: SD.h library
|
||
|
automatically writes and updates the file of the SD card in chunks of
|
||
|
512 bytes (it has its own buffer). The buffer is written to the card
|
||
|
whenever .flush() or .close() is performed or when it actually gets
|
||
|
full. Writing in chunks is generally better because we won't need to
|
||
|
open and close the file every time we want to write (and this consumes a
|
||
|
considerable amount of time). Considering this, if we rely on the
|
||
|
library and the card controller to manage the timing of the physical
|
||
|
storage, we'll have new data being saved every time the buffer gets
|
||
|
totally filled, so, if we get sensors' information every 100ms, and if
|
||
|
each line of the file is about 50 bytes, we will have 10 logs being
|
||
|
effectively appended to the file every one second. Is this enough?
|
||
|
|
||
|
Another way of doing this would be opening and closing the file in each
|
||
|
iteration, which means that any placement of data into the buffer, in
|
||
|
each iteration, would be successfully written. However, this can lead to
|
||
|
a bad performance and we don't want a big delay between all those
|
||
|
operations. It's a matter of testing and seeing which option is the
|
||
|
best.
|
||
|
|
||
|
Maybe the best solution is the buffer approach. We need to test if the
|
||
|
native SD.h library 512 bytes buffer is reliable enough, otherwise, we
|
||
|
may want to work on our own buffer with a custom size, until we find the
|
||
|
best balance between writing speed and data safety.
|
||
|
|
||
|
Logging Using Telecommunications
|
||
|
================================
|
||
|
|
||
|
The team is supposed to use a LoRa or a XBee antenna to send the exact
|
||
|
same data to the ground station. In order to implement this, we will
|
||
|
need to configure both the transmitter, to send data, and the receiver,
|
||
|
that will be on the ground station.
|
||
|
|
||
|
We want this transmission of data to be as quick as possible because we
|
||
|
want to have live updates of the values we will be tracking. It would
|
||
|
probably be enough/satisfying if we could send a new csv string to the
|
||
|
ground station every 100ms as well. However, the velocity of
|
||
|
transmission will depend on the distance between the receiver and the
|
||
|
transmitter, which means that at a certain altitude we may face a big
|
||
|
decrease on the transmission of data, which is not desirable, but I
|
||
|
actually didn't find clear information about this and the Electrical
|
||
|
Engineering Team is still deciding the best antennas to use. With more
|
||
|
information and knowing the boundaries that assure us a stable and
|
||
|
constant transmission, it will be possible to decide a suitable
|
||
|
configuration.
|
||
|
|
||
|
Those articles show a C implementation of communication between two
|
||
|
Arduino or ESP32 using Lora and its own library; they can be a good
|
||
|
start point. [ESP32 with LoRa using Arduino IDE -- Getting
|
||
|
Started](https://randomnerdtutorials.com/esp32-lora-rfm95-transceiver-arduino-ide)
|
||
|
and [Introduction to Lora -- Send data between two Arduino using
|
||
|
Lora](https://www.electronics-lab.com/project/introduction-lora-send-data-two-arduino-using-lora/).
|
||
|
|
||
|
Veredict
|
||
|
========
|
||
|
|
||
|
We need to test some basic implementations of Backup Logging System and
|
||
|
start benchmarking at different rates of data acquisition to check if
|
||
|
there's significant delay between reading from the sensors and writing
|
||
|
to the file, in order to have a stable logging system. This is very
|
||
|
important to make sure that the existing libraries satisfy our needs,
|
||
|
otherwise, we may need to compact libraries or improve an existing one
|
||
|
to get better results.
|
||
|
|
||
|
When it comes to the telecommunications, it is still difficult to make a
|
||
|
deeper study of implementation. We can actually put two microcontrollers
|
||
|
communicating with each other but, apart from testing (which is very
|
||
|
important), there is still lack of information from other departments
|
||
|
such as the position of the antenna(s), if it is going to be a Lora or a
|
||
|
XBee, how strong the connection is gonna be and how it is going to vary,
|
||
|
etc. This is a crucial information as it simplifies our research on the
|
||
|
most suitable libraries and functionalities.
|
||
|
|
||
|
Logging system will have to work flawlessly and coherently: we need to
|
||
|
make sure that the lag between the logs obtained by these two different
|
||
|
ways is minimal. This coherence and "parallelism\" between the Backup
|
||
|
Logging System and the Real-Time Logging System is a little bit hard to
|
||
|
predict without trying and testing.
|
||
|
|
||
|
A research about 4G/5G broadband networking data transmission and its
|
||
|
implementation along with the other two would be interesting, but it's
|
||
|
still not decided if we're actually going to use this (it depends on the
|
||
|
decision of the Electrical Engineering Department).
|
||
|
|
||
|
References
|
||
|
==========
|
||
|
|
||
|
\[1\] Arduino Forum;
|
||
|
|
||
|
\[2\] [Arduino Rocket Data
|
||
|
Logger](https://www.instructables.com/Arduino-Rocket-Data-Logger/).
|
||
|
|
||
|
\[3\] [ESP32 with LoRa using Arduino IDE -- Getting
|
||
|
Started](https://randomnerdtutorials.com/esp32-lora-rfm95-transceiver-arduino-ide);
|
||
|
|
||
|
\[4\] [Introduction to Lora -- Send data between two Arduino using
|
||
|
Lora](https://www.electronics-lab.com/project/introduction-lora-send-data-two-arduino-using-lora/);
|