Agrégation informatique externe 2025, épreuve 3, option ingénierie informatiqueSujet et rapport du jury

AGRÉGATION
CONCOURS EXTERNE

CONCEPTION PRÉLIMINAIRE D'UN SYSTÈME, D'UN PROCÉDÉ OU D'UNE ORGANISATION

INFORMATION AUX CANDIDATS

Ces codes doivent être reportés sur chacune des copies que vous remettrez.

• -d'un dossier questionnement de la page 2 à la page 24 ;
  • -Présentation : de la page 2 à la page 2;
  • -Partie 1 : de la page 3 à la page 12;
  • -Partie 2 : de la page 13 à la page 16 ;
  • -Partie 3 : de la page 17 à la page 21 ;
  • -Partie 4 : de la page 22 à la page 24 ;
• -des documents techniques à partir de la page 25.

• -les parties du questionnement sont indépendantes;
• -un parcours attentif de l'ensemble du document est conseillé avant de composer ;
• -la présentation des programmes doit respecter les mots clés du langage cible ainsi que l'indentation des structures algorithmiques ;
• -les réponses doivent être présentées avec clarté, rigueur et concision.

Spectacles de drones

Présentation du système

• -La gamme Chambord pour des spectacles lumineux en extérieur (1024 drones).
• -La gamme Versailles adaptée pour les départs sur plans d'eau (flotte de 256 drones).
• -La gamme Grande arche adaptée pour les environnements urbains nécessitant une grande précision dans les déplacements pour l'évitement des structures et bâtiments (flotte de 128 drones).

Composition technique d'un système pour un évènement

• -Un ensemble de drones, identiques ou non. Le nombre de drones dépend des besoins de la direction artistique et influe directement sur les solutions techniques retenues.
• -Une base au sol permettant d'accueillir les drones avant la mission, d'assurer leur charge ainsi qu'une zone de retour (deux bases peuvent être nécessaires selon les missions).
• -Une station de commande au sol permettant de gérer la préparation, le déroulement et l'exécution de la fin de mission.
• -Une infrastructure de communication pour gérer la télémétrie, les situations d'urgences et la synchronisation des drones.

• -La première partie est consacrée à l'analyse de la commande des moteurs d'un quadricoptère à partir des consignes de pilotage et des capteurs du contrôleur embarqué.
• -La deuxième partie s'intéresse à une gamme de drones équipés de détecteur d'obstacles 360° utilisant la technologie laser afin d'éviter les obstacles dans le cas d'une utilisation de l'essaim dans un environnement contraint.
• -La troisième partie s'intéresse aux aspects embarqués du système de télémétrie.
• -La quatrième partie traitera des aspects logiciels pour le support aux équipes de suivi et de maintenance.

Première partie Analyse d'un drone quadricoptère

Sous-partie 1.1 : Modélisation

Figure 1 - Référentiels et conventions adoptées pour le drone

• -L'angle de roulis noté θ sur la figure 1 correspond à l'angle entre le référentiel fixe de centre O et du référentiel mobile de centre G (celui du drone) autour de l'axe x.
• -L'angle de tangage noté φ sur la figure 1 correspond à l'angle entre le référentiel fixe de centre O et du référentiel mobile de centre G (celui du drone) autour de l'axe y.
• -L'angle de lacet noté ψ sur la figure 1 correspond à l'angle entre le référentiel fixe de centre O et du référentiel mobile de centre G (celui du drone) autour de l'axe z.

Figure 2 - Pilotage des moteurs et actions sur le drone

Sous-partie 1.2 : Détermination des paramètres pour la simulation du drone sous Matlab

• -Masse initiale du drone mesurée par la balance : 632 g
• -Masse du drone mesurée pour une vitesse de rotation des hélices de 1100 tr/min : 612 g

Sous-partie 1.3 : Fonctionnement du contrôleur de vol

Figure 3 - Diagramme fonctionnel calculateur embarqué

Sous-partie 1.4 : Variateurs de vitesse électroniques des moteurs

Figure 4 - Diagramme fonctionnel d'un Electronic Speed Controller (ESC)

• -Sens trigonométrique 0 à 100% : 1100μ s à 1500μ s
• -Bande morte ou vitesse nulle : 1500μ s à 1540μ s
• -Sens horaire 0 à 100% : 1540μ s à 1940μ s

Figure 5 - Diagramme de classes partiel

Figure 6 - Communication sur le bus I^2 C

• -Le calculateur embarqué utilise un système d'exploitation linux connecté au bus I^2 C
• -Le MPU9255 contient un gyromètre 3 axes, un accéléromètre 3 axes et un magnétomètre 3 axes

Figure 7 - Trame relevée sur le bus I^2 C

Figure 8 - Diagramme de classes partiel du capteur MPU9255

Sous-partie 1.5 : Synthèse du correcteur PID de l'angle de lacet

Figure 9 - Diagramme du correcteur PID parallèle

Figure 10 - Diagramme de la classe PID

• -On annule l'action intégrale et l'action dérivée.
• -L'action proportionnelle est augmentée jusqu'à ce que le signal en sortie de la boucle fermée oscille de manière entretenue. On note alors ce gain K_u correspondant au gain maximal (ou gain critique).
• -On note T_u la période d'oscillation du signal. Les paramètres K_p, K_i et K_d du régulateur, sont choisis en se référant au tableau de la figure 11.

Figure 12 - Schéma de simulation de l'asservissement du drone en altitude

Figure 13 - Relevé asservissement d'altitude pour un gain critique K_u = 3

Figure 14 - Relevés lors des essais suite un échelon de d'altitude de 4 m

Sous-partie 1.6 : Logique de commande du drone

void* motors(void* arg)
{
    // instanciation des objets de la classe Motor
    Motor m1 = new Motor(1,true);
    Motor m2 = new Motor(2,false);
    Motor m3 = new Motor(3,true);
    Motor m4 = new Motor(4,false);
    // instanciation des objets de la classe PID à partir
    // des paramètres PID identifié par la méthode Zieglers- Nichols.
    // Roll: Tangage
    // Pitch: Roulis
    // Yaw: Lacet
    PID pidRoll = new PID(kpr, kir, kdr);
    PID pidPitch = new PID(kpp, kip, kdp);

    PID pidYaw = new PID(kpy, kiy, kdy);
    PID pidAltitude = new PID(kpa, kia, kda);
    // calculs des PID
    outPIDRoll = pidRoll->correction(refRoll, measRoll);
    outPIDPitch = pidPitch->correction (refPitch, measPitch);
    outPIDYaw = pidYaw->correction (refYaw, measYaw);
    outPIDAltitude = pidAltitude->correction (refAltitude, measAltitude);
    // calculs des vitesses de chaque moteur (zone A à compléter sur votre copie)
    speedM1 =
    speedM2 =
    speedM3 =
    speedM4 =
    // commande en vitesse de chaque moteur (zone B à compléter sur votre copie)
}

Deuxième partie

Détection d'obstacles par LIDAR 360 pour la gamme Grande arche

#include <pthread.h>
#include <mutex>
#include <math.h>
class Lidar360
{
    ComSerie *com;
    unsigned char *trame;
    uint32_t ** dataLidar;
    mutex mx;

public:
    Lidar360(string port);
    void lireTrame();
    void stockerDataLidar();
    bool checksum();
    uint32_t[] rechercheObstacle(int indiceMin, int indiceMax);
    float deviationCap(uint32_t seuil, float largeurDrone);
};

#define NO 0
#define ODD 1
#define EVEN 2
public:
    ComSerie();
    ComSerie(const std::string portCom, unsigned int vitesse, unsigned int parite);
    ~ComSerie();

int recevoir(unsigned char * trame, unsigned char nbOctets);

• -une méthode lock() qui permet de verrouiller l'accès à la zone mémoire critique,
• -une méthode unlock() qui permet de déverrouiller l'accès à la zone mémoire critique.

• -Si la valeur de distance à l'obstacle est inférieure à un seuil de distance pris en argument de la méthode en mètres sur l'un des deux secteurs d'angles avant droit ou gauche, la méthode renverra un angle de déviation 40 fois l'inverse de la distance à l'obstacle.
• -Si deux obstacles sont détectés sur les secteurs avant droit et gauche :
  • -Si le drone peut passer alors on renvoie l'angle médian entre les 2 obstacles,
  • -Si le drone ne peut pas passer alors on déviera le drone du coté où la distance à l'obstacle est la plus grande en ajoutant l'angle de déviation correspondant à deux fois la largeur du drone.
• -S'il n'y a pas d'obstacle, la méthode renverra 0.

Figure 15 - Passage du drone entre 2 obstacles

Troisième partie

Télémetrie

• -Le drone présente un fonctionnement nominal et dispose d'une charge suffisante pour la mission.
• -Le drone présente un défaut ne lui permettant pas de participer à l'évènement,
• -Le drone présente un défaut pendant l'évènement nécessitant une action (extinction des lumières, évacuation du dispositif),
• -Le drone présente un défaut ne lui permettant pas de rejoindre sa base au sol à l'issue de l'évènement et nécessitant alors une procédure de localisation et de récupération.

Sous-partie 3.1 : Spécifications

• -Un identifiant unique pour identifier le drone,
• -le niveau de charge de la batterie,
• -la position GPS complète,
• -un code sur un octet représentant l'état du drone (cf table 1).

Sous-partie 3.2 : Mise en forme des données

Coordonnées de localisation

$GPRMC, 173523.000 ,A,4838.4880,N,00148.8110,E,0.00,307.09,230524,,,A,V*1C
2 $GPGGA,173523.000,4838.4880,N,00148.8110,E,1,7,1.0,199.6,M,0.0,M, ,*5A
3 $GNGSA,A,3,19,17,06,09,.,.,.,.,2.16,1.92,0.99,1*0F
4 $GNGSA,A,3,87,71,72,,,,,,,,,,2.16,1.92,0.99,2*01
5 $GNGLL,4838.49,N,00148.81,E,173523.000,A,A*48

Niveau de tension de la batterie

uint16_t mesure_tension_batterie() {
    uint16_t AD_RES = 0;
    // Conversion
    HAL_ADC_Start(&hadc1);
    // Attente de fin de conversion
    HAL_ADC_PollForConversion(&hadc1, 1);
    // Lecture
    AD_RES = HAL_ADC_GetValue(&hadc1);
    // Mise a l'echelle
    uint16_t vbat = a completer sur votre copie
    return vbat;
}

Identifiant unique

UID[31:0]: X and Y coordinates on the wafer expressed in BCD format
UID[63:40]: LOT_NUM[23:0] Lot number (ASCII encoded)
UID[39:32]: WAF_NUM[7:0] Wafer number (8-bit unsigned number)
UID[95:64]: LOT_NUM[55:24] Lot number (ASCII encoded)

Code d'état

Structure de données

Sous-partie 3.3 : Réseau zigbee

Quatrième partie Suite logicielle

Sous-partie 4.1 : Organisation générale

• -Un courtier MQTT,
• -un programme python qui scrute la liaison série et publie les informations sur le courtier dans les topics : topic/batterie, topic/position et topic/etat.

Figure 18 - Architecture du système de télémétrie

Courtier MQTT

• -Data logger : service distant qui enregistre tous les évènements pour l'analyse qualité à posteriori.
• -Surveillance mission live : service utilisable localement ou à distance pour surveiller l'exécution des missions.

• -Search and rescue : service local qui utilise des services de cartographie pour permettre de publier sur une interface web la localisation et la récupération des drones accidentés ou hors zone.

Sous-partie 4.2 : Conception du service Moniteur

Moniteur de flotte

• -Surveiller les mises à jour de position de chaque drone et d'ajouter dans une base de données : les nouveaux drones, l'instant du dernier contact et leur position. Le système n'aura pas besoin de connaître la liste des drones avant la mission.
• -Mettre à jour dans la base de données, l'horodatage du dernier message à l'arrivée de chaque nouveau message.
• -Inspecter la base de données pour trouver l'ensemble des drones dont l'horodatage est plus distant de l'instant présent qu'une valeur définie par avance (on considère alors le contact perdu).
• -Publier l'ID du drone, l'instant de la perte de contact et la dernière position connue sur le topic topic/perdus.

Gestion du courtier mqtt

Gestion de la base de données

Moniteur

Disparition de trames

Document techniques

Motor	PWM
-channel : unsigned int -direction : bool -pwm : PWM*	+PWM() +init(insigned int channel) : bool +enable(unsigned int channel) : bool +set_period(unsigned int channel, unsigned int freq) : bool +set_duty_cycle(unsigned int channel, float period) : bool
+Motor(unsigned int channel, bool direction) +Motor() +initialize(unsigned int frequency) : bool +enable() : bool +calculatePercentageSpeed(double eAltitude, double eRoll, double ePitch, double eYaw) : double +setPulse(double percentageSpeed) 4 - pMotor 1 Drone -lidar : Lidar360 -Motors : pThread* -Sensors : pThread* PID -_Kp : double -_Ki : double -_Kd : double -_lastTime : double -_lastValue : double -_sumError : double +PID(double Kp, double Ki, double Kd) +correction(double reference, double measure) : double	I2C +12C() +read(uint8_t addr, uint8_t adrReg, uint8_t nbReg, buf : uint8_t *) : int32_t +write(uint8_t adrModule, uint8_t adrReg, uint8_t donnee) : int32_t -mpu9255 Sensors +Sensors() +getPosition() : double* +getEuler() : double* +getAltitudeXYZ() : double +getCap() : double ComSerie -com : int +ComSerie() +ComSerie(const std::string portCom, unsigned int vitesse, unsigned int parite) +receive(trame : unsigned char*, unsigned char nbOctets) : string +send(String)

DT2 Extrait du document MPU-9255

1 Product Overview

2 Features

2.1 Gyroscope Features

2.2 Accelerometer Features

2.3 Magnetometer Features

2.4 Additional Features

2.5 Block Diagram

4 Communication

Complete I2C Data Transfer

DT3 Extrait de la documentation du LIDAR N10

1. Product description

The Lidar N10 consists mainly of a laser ranging core, a wireless power transmission unit, a wireless communication unit, an angle measuring unit, a motor drive unit and a mechanical housing. With DTOF technology, Lidar N10 ranging core is able to perform 4,800 measurements per second. For each ranging, the LiDAR emits an infrared laser, which is reflected back to the single photon receiving unit when it encounters the target object. From this, we obtain the time at which the laser is emitted and that at which it is received by the single photon receiving unit. The time difference between them is the time of flight of the light, which can be combined with the speed of light to solve for the distance. Once the distance data have been obtained, Lidar N10 fuses the angle values measured by the angle measuring unit to form the point cloud data and then sends the point cloud data of 58 bytes to an external interface via wireless communication. Meanwhile the external interface supports PWM input to enable the motor drive unit to drive the motor rotation. The external control unit obtains the speed and controls it to the specified speed by means of a PID algorithm in closed-loop control, this allowing the LiDAR to work stably. The diagram of the environmental scan formed by Lidar N10 point cloud data is shown below:

2 Serial Port Configuration

3 Point Cloud Output Protocol

1. Byte_0 - Byte_1: frame header, fixed.
2. Byte_2: the length of the data frame, from the frame header to checkbit.
3. Byte_3 - Byte_4: motor speed, in μs, the most significant value in the sequence is stored first, at the lowest storage address while the least significant value is stored at the highest storage address.
   For example: Speed_H=0x10, Speed_L=0×46, i.e. 0 × 1046=>4166μ s. Time for one revolution of the code disk: 4166μ s^∗ 24 = 100 ms , i.e. speed 10 Hz
4. Byte_5- Byte_6: the starting angle of a frame of data, with the high bit in front. It is 100 times of the actual angle. Example: Start_angle_H=0x42, Start_angle_L=0x08, i.e. 0 × 4208=>16904=>169.04^∘.
5. Byte_7- Byte_54: Point cloud data. Each data includes 2 bytes of distance and 1 byte of intensity information, with the high bit first and the distance in mm For example: Distance_1_H=0x00, Distance_1_L=0X64, PEAK_1=0x64, meaning distance: 0x64=100mm, intensity: 100.
6. Byte_55- Byte_56: End angle. Calculation method is the same as start angle. 7) Byte_57: data and checksum from Byte_0 to Byte_56. CKS = byte0 + byte1 +...+ byte56

DT4 Structures des trames NMEA

$<talker ID><Trame type>[,<données>,<données>]*<checksum>

Talker ID

• -BD ou GB - Beidou ;
• -GA - Galileo;
• -GP - GPS ;
• -GL - GLONASS.

Type de trames

Quelques exemples de types de trames :

$GPGGA,064036.289,4836.5375,N,00740.9373,E,1,04,3.2,200.2,M,,,,0000*0E
$GPGGA : Type de trame
064036.289 : Trame envoyée à 06 h 40 min 36 s 289 (heure UTC)
4836.5375,N : Latitude exprimée en ddmm.mmmm: 48° 36.5375' Nord
00740.9373,E : Longitude exprimée en dddmm.mmmm: 7° 40,9373' Est
1 : Type de positionnement (le 1 est un positionnement GPS)
04 : Nombre de satellites utilisés pour calculer les coordonnées
3.2 : Précision horizontale ou HDOP (Horizontal dilution of precision)

200.2,M : Altitude 200,2, en mètres
,,,,,0000 : D'autres informations peuvent être inscrites dans ces champs
* : séparateur de checksum
OE : Somme de contrôle de parité, un simple XOR sur les caractères entre $ et *4

$GPRMC,053740.000,A,2503.6319,N,12136.0099,E,2.69,79.65,100106,,,A*53

$GPGLL,4916.45,N,12311.12,W,225444,A*31

$GPGSA,A,3,21,30,31,06,24,29,,,,,,,2.8,1.5,2.4*33

DT5 Schéma de la carte Télémétrie

DT6 ADC STM32

DT7 Structure d'un réseau zigbee

• -Coordinateur : il initialise et contrôle le réseau. Il est unique dans chaque réseau.
• -Routeur : il retransmet les messages entre les nœuds et peut également agir comme coordinateur en cas de défaillance du coordinateur principal. Chaque routeur étend la portée du réseau à son voisinage.
• -Terminal : il ne peut pas relayer les messages et est généralement alimenté par batterie.

• -Étoile : un coordinateur central contrôle tous les autres nœuds du réseau. Les nœuds terminaux communiquent directement avec le coordinateur. Toute défaillance du coordinateur entraîne l'arrêt du réseau. La portée est limitée par la distance entre les nœuds et le coordinateur.
• -Arbre : un coordinateur à la racine et des routeurs formant des branches. Les nœuds terminaux sont connectés aux feuilles de l'arbre. La défaillance d'un nœud n'affecte qu'une partie du réseau.
• -Maillée : chaque nœud peut communiquer directement avec plusieurs autres nœuds, créant ainsi un réseau interconnecté. La défaillance d'un nœud peut être contournée par d'autres chemins.

(a) Typologie de noeuds

(b) Étoile

(c) Arbre

(d) Maillé

DT8 Structure générale d'une trame XBee en mode API

Digi > API Mode > API frame structure

Start delimiter

Length

Frame data

• -Frame type is the API frame type identifier. It determines the type of API frame and indicates how the information is organized in the Data field.
• -Data contains the data itself. The information included here and its order depends on the type of frame defined in the Frame type field.

DT9 Transmit Request frame

Description

64-bit addressing

Zigbee-specific addressing information

• -Set the 64-bit address to all 0x00s and the 16-bit address to 0xFFFE
• -Set the 64-bit address to the coordinator's 64-bit address and the 16-bit address to 0x0000

Format

DT10 Documentation simplifiée de paho.mqtt.client

• -Use connect() to connect to a broker
• -Use loop_start() to set a thread running to call loop() for you.
• -Or use loop_forever() to handle calling loop() for you in a blocking function.
• -Or call loop() frequently to maintain network traffic flow with the broker
• -Use subscribe() to subscribe to a topic and receive messages
• -Use publish() to send messages
• -Use disconnect() to disconnect from the broker

Callbacks

def on_connect(client, userdata, flags, reason_code, properties):
    print(f"Connected with result code {reason_code}")
client.on_connect = on_connect

Methods

connect(host: str, port: int = 1883, keepalive: int = 60, bind_address: str = '',
    bind_port: int = 0, clean_start: bool | Literal[3] = 3,
    properties: Properties | None = None) -> MQTTErrorCode

• -host (str) - the hostname or IP address of the remote broker.
• -port (int) - the network port of the server host to connect to. Defaults to 1883. Note that the default port for MQTT over SSL/TLS is 8883 so if you are using tls_set() the port may need providing.
• -keepalive (int) - Maximum period in seconds between communications with the broker. If no other messages are being exchanged, this controls the rate at which the client will send ping messages to the broker.
• -clean_start (bool) - (MQTT v5.0 only) True, False or MQTT_CLEAN_START_FIRST_ONLY. Sets the MQTT v5.0 clean_start flag always, never or on the first successful connect only, respectively. MQTT session data (such as outstanding messages and subscriptions) is cleared on successful connect when the clean_start flag is set. For MQTT v3.1.1, the clean_session argument of Client should be used for similar result.
• -properties (Properties) - (MQTT v5.0 only) the MQTT v5.0 properties to be sent in the MQTT connect packet.

loop_forever(timeout: float = 1.0, retry_first_connection: bool = False) -> MQTTErrorCode

• -timeout (int) - The time in seconds to wait for incoming/outgoing network traffic before timing out and returning.
• -retry_first_connection (bool) - Should the first connection attempt be retried on failure. This is independent of the reconnect_on_failure setting.

publish(topic: str, payload: str | bytes | bytearray | int | float | None = None,
    qos: int = 0, retain: bool = False, properties: Properties | None = None)
    -> MQTTMessageInfo

• -topic (str) - The topic that the message should be published on.
• -payload - The actual message to send. If not given, or set to None a zero length message will be used. Passing an int or float will result in the payload being converted to a string representing that number. If you wish to send a true int/float, use struct.pack() to create the payload you require.
• -qos (int) - The quality of service level to use.
• -retain (bool) - If set to true, the message will be set as the "last known good"/retained message for the topic.
• -properties (Properties) - (MQTT v5.0 only) the MQTT v5.0 properties to be included.

subscribe(topic: str, qos: int = 0) -> tuple[MQTTErrorCode, int | None]

• subscribe("my/topic", 2)
• -topic: A string specifying the subscription topic to subscribe to.
• -qos: The desired quality of service level for the subscription. Defaults to 0.

Remarks on QoS

• -QoS Level 0 - at most once: This is the simplest, lowest-overhead method of sending a message. The client simply publishes the message, and there is no acknowledgement by the broker.
• -QoS Level 1 - at least once: This method guarantees that the message will be transferred successfully to the broker.
  The broker sends an acknowledgement back to the sender, but in the event that that the acknowledgement is lost the sender won't realise the message has got through, so will send the message again. The client will re-send until it gets the broker's acknowledgement.
  This means that sending is guaranteed, although the message may reach the broker more than once.
• -QoS Level 2 - exactly once: This is the highest level of service, in which there is a sequence of four messages between the sender and the receiver, a kind of handshake to confirm that the main message has been sent and that the acknowledgement has been received.
  When the handshake has been completed, both sender and receiver are sure that the message was sent exactly once.

DT11 Référence SQLite et usage avec python

INSERT

Forme basique

INSERT INTO table (column1 [, column2, column3 ... ]) VALUES (value1 [, value2, value3 ... ])

INSERT INTO film_cast (firstname, lastname) VALUES ('Raoul', 'Duke')

UPDATE

• -Soit toutes les lignes peuvent être mises à jour,
• -soit un sous-ensemble peut être choisi à l'aide d'une condition.

Forme basique

UPDATE table_name SET column_name = value [, column_name = value ...] [WHERE condition]

Paramètres nommés avec des dictionnaires dans SQLite3

requete = "SELECT * FROM utilisateurs WHERE age = :age"
cursor.execute(requete, {'age': 24})

"SELECT * FROM utilisateurs WHERE age = 24"

DT12 Service Moniteur - Codes

            ecoute_mqtt.py
import paho.mqtt.client as mqtt
import threading
class EcouteMQTT:
    def __init__(self, broker_address, port, topics = None):
        self.client = mqtt.Client()
        self.client.on_connect = self.on_connect
        self.client.on_message = self.on_message
        self.topics = topics
        self.broker_address = broker_address
        self.port = port
        self.t = threading.Thread(target=self.client.loop_forever)
        # self.verrou = False
        self.messages = []
    def on_connect(self, client, userdata, flags, rc):
        print(f"Connecté au broker {self.broker_address} - code de retour {str(rc)}")
        for topic in self.topics :
            self.client.subscribe(f"{topic}")
    def on_message(self, client, userdata, msg):
        self.messages.append(msg.payload.decode("utf-8"))
    def start(self):
        self.client.connect(self.broker_address, self.port)
        self.t.start()
    def stop(self):
        self.client.disconnect()

        gestion_db.py

            else:
                self.cursor.execute(query)
            self.conn.commit()
            return self.cursor.fetchall()
    except sqlite3.Error as e:
            print(f"Une erreur s'est produite : {e}")
            return None
def insert_or_update(self, datas):
    try:
            self.cursor.execute(self.insert_rq, datas)
    except sqlite3.IntegrityError:
            self.cursor.execute(self.update_rq, datas)
def affiche(self):
    requete = f"SELECT * FROM drones"
    self.cursor.execute(requete)
    self.conn.commit()
    messages = (self.cursor.fetchall())
    for message in messages:
        print(message)
    print("\n\n")
def close(self):
    self.conn.close()

        mqtt_monitor.py
import datetime, time
from ecoute_mqtt import EcouteMQTT
from gestion_db import SQLiteManager
def main():
    """ Service qui récupère les messages MQTT du topic ?????? et
    ajoute les données à la base de donnée sqlite moniteur.db """
    ecoute = EcouteMQTT(A COMPLÉTER)
    ecoute.start()
    database = SQLiteManager("moniteur.db")
    # Création d'une table (exemple)
    database.execute(database.create_rq)
    while True:
        time.sleep(1)
        if len(ecoute.messages) > 0:
            for message in ecoute.messages:
                payload_str = message
                data = payload_str.split(':')
                datas = {'id': data[0],
                    'new_date' : datetime.datetime.now().isoformat("T","seconds"),
                    'lat' : data[1],
                    'long' : data[2],
                    'alt' : data[3],}

            # Insertion de données
            database.insert_or_update(datas)
            database.affiche()
            ecoute.messages = []

        moniteur.py