mirror of
https://codeberg.org/portospaceteam/E-42.git
synced 2024-10-31 22:09:44 +00:00
Eliminar 'members/luis-jesus/reports/sitrep1.md'
This commit is contained in:
Luís Jesus
parent
dd3412000b
commit
c5d937b42f
@ -1,179 +0,0 @@
|
|||||||
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/);
|
|
||||||
Loading…
Reference in New Issue
Block a user