Rapid Prototyping | Prototypage rapide de commande

Boîte à outils UxV

Mon, 01 Jul 2019 00:00:00 +0000

Vue d’ensemble

La boîte à outils UxV pour Matlab/Simulink fournit des scripts Matlab et des blocs Simulink pour les drones (UAV) pour traiter le protocole MAVLink, le GPS, les récepteurs RC et les protocoles de télémétrie.

Scripts Matlab pour l’analyse des données après vol (MAVLink).
Blocs Simulink pour concevoir un pilote automatique à partir d’un modèle (prototypage rapide des commandes avec Simulink).

Ces outils de conception et d’analyse fondés sur un modèle accélèrent les allers-retours entre les essais expérimentaux et la simulation.

Scripts Matlab pour MAVLink

Trois scripts principaux permettent de décoder les messages MAVLink, de créer un modèle Simulink de simulation à partir des données enregistrées, et de générer la trace de la trajectoire sur une carte à partir des messages GPS.

Script	Entrée	Sortie	Fonction
(1) mavlink2mat	Journal Mavlink	.mat	analyse dans Matlab
(2) mavlink2simulink	Journal Mavlink	.mat / .mdl (.slx)	simulation à partir de données réelles
(3) mavlink2kml	Journal Mavlink	.kml	tracé de la ou des traces GPS sur une carte
mavlink2gui	Journal Mavlink	GUI	exploration graphique d’un journal MAVLink

Le script mavlinkgui ouvre une interface graphique (GUI) pour explorer les données MAVLink. Il liste les messages MAVLink présents dans un fichier journal et trace les {message - valeur} sélectionnés. Le script de tracé est personnalisable : l’utilisateur peut ainsi aller au-delà d’un simple tracé. L’interface donne accès aux trois scripts mentionnés ci-dessus.

Blocs Simulink

10 blocs ajoutés apportent les fonctions essentielles d’un UAV pour mettre en œuvre un pilote automatique sur un DSC dsPIC. Ces blocs complètent les blocs MPLAB pour Simulink de Microchip, qui fournissent les blocs de périphériques pour la génération de code. Ils s’appuient sur MathWorks Embedded Coder. Les fonctions ajoutées sont les suivantes :

GPS
- GPS Parser pour décoder les messages NMEA
MATH
- Quaternion to Cardan FxPt pour convertir un quaternion en angles de Cardan en virgule fixe (similaires aux angles d’Euler)
MAVLink :
- SEND (envoyer un message)
- RECEIVE (recevoir un message)
- MAVLink Data (données de points de passage)
- MAVLink Parser (décode le message d’entrée et met en œuvre les protocoles WayPoint¹ et Parameter²)
Récepteurs-Télémétrie
- S.BUS reçoit les canaux RC
- Smart Port envoie les valeurs de télémétrie
- F.Port reçoit les canaux RC + envoie la télémétrie
- Sensor for Smart.Port or F.Port définit les valeurs à envoyer par télémétrie³

À l’exception du bloc MATH, ces blocs se connectent généralement aux blocs UART Rx/Tx du dsPIC pour envoyer ou recevoir le flux de données d’un GPS, d’un récepteur ou d’une liaison radio.

Installation

Ces blocs sont développés par Lubin Kerhuel et diffusés gratuitement avec les MPLAB device blocks for Simulink de Microchip.

Installer les MPLAB Device Blocks de Microchip
Saisir pinInfo, puis cliquer sur go to Third Part Tools folder
Exécuter le script UxV_Blockset_Installer.p dans le dossier UxV_blockset.

Le protocole Way Point sert à définir et à lire des points de passage (WayPoint) depuis une station au sol compatible MAVLink. ↩︎
Le protocole Parameter règle, depuis n’importe quelle station au sol MAVLink, les paramètres ajustables de Simulink, habituellement modifiés avec l’External Mode ou lors d’une simulation Processor In the Loop (PIL). ↩︎
Le bloc Sensor for Smart.Port or F.Port s’utilise avec le bloc Smart Port ou le bloc F.Port. Ces protocoles renvoient des paquets de télémétrie vers l’interface de la radiocommande (RC). Il est ainsi possible d’émuler aisément des capteurs Frsky (tension et courant de batterie, variomètre, vitesse air, GPS) et d’ajouter des fonctions à la radiocommande. Il est également possible d’émuler la télémétrie BetaFlight. Utilisés avec un script LUA, ils ajoutent des fonctions telles que l’horizon artificiel, la vitesse air, la vitesse verticale, la distance au point de départ et d’autres fonctions (évalué avec les scripts LUA yaapu). ↩︎

bloc récepteur & télémétrie : S.BUS, Smart Port, F.Port

Mon, 01 Jan 0001 00:00:00 +0000

Trois blocs ajoutent la prise en charge de trois protocoles présents sur les récepteurs. Un récepteur traditionnel à sortie PWM se traite directement avec le périphérique Input Capture ou Change Notification : il n’exige pas de bloc spécifique.

S.BUS, Smart Port et F.Port

S.BUS, Smart Port (également appelé S.Port) et F.Port sont trois protocoles disponibles sur les récepteurs RC FrSky et compatibles. Les trois protocoles reposent sur le périphérique UART avec des réglages différents. Chacun remplit un rôle propre :

S.BUS est un protocole unidirectionnel du récepteur vers un équipement externe, qui fournit les valeurs des canaux et le RSSI¹ (c.-à-d. la qualité de la liaison radio).
Smart Port (S.Port) est un protocole bidirectionnel. Le récepteur interroge (ping) les différents capteurs connectés et acquiert les mesures à envoyer par télémétrie à la radiocommande.
F.Port est un protocole bidirectionnel dans lequel le récepteur communique les valeurs des canaux et le RSSI, et obtient les valeurs des capteurs connectés pour les envoyer par télémétrie à la radiocommande.

Les deux protocoles bidirectionnels Smart Port et F.Port utilisent un seul fil pour Tx et Rx. La communication s’effectue en mode half duplex (semi-duplex).

Les récepteurs FrSky existent en deux variantes (modèles livrés avec le Smart Port : x4r, rx4r, x6r, s6r, rx6r, x8r, s8r, xsr, xsr-m, r-xsr …) :

S.Bus & Smart Port (d’origine), disponibles sur deux ports à trois broches distincts
F.Port disponible sur un unique port à trois broches, qui remplace le Smart Port

Un récepteur d’origine possède deux ports : S.BUS et Smart Port. Le passage à un F.Port unique s’effectue en installant un micrologiciel alternatif fourni par FrSky. Ce micrologiciel supprime le port S.BUS et convertit le Smart Port en F.Port.

Réglages UART et mise en œuvre

S.BUS, S.Port et F.Port ont des réglages UART différents, définis dans le tableau :

	Débit (baud)	Duplex	Logique	Parité	Bits de stop	Contrôle de flux
S.BUS	100000	Rx seul	3,3V inversée	paire	2	non
Smart Port	57600	Half	3,3V inversée	aucune	1	non
F.Port	115200	Half	3,3V inversée	aucune	1	non

La mise en œuvre sur dsPIC avec le bloc MPLAB pour Simulink a donné des résultats satisfaisants avec les réglages ci-dessous, définis dans le bloc UART Configuration :

	Mise en œuvre	Taille du tampon	Priorité d’interruption
S.BUS Rx	Circular Buffer	64	5
S.BUS Tx	None	-	-
Smart Port Rx	Circular Buffer	32	5
Smart Port Tx	Circular Buffer	32	6
F.Port Rx	Circular Buffer	32	5
F.Port Tx	Circular Buffer	64	5

Connexion des blocs Simulink S.BUS, Smart Port et F.Port à l’UART Rx & Tx

Les blocs S.Bus, F.Port et Smart Port xxx prennent le flux de sortie du récepteur pour en extraire les valeurs de commande envoyées par la radiocommande. Le flux d’entrée est un vecteur dont la longueur est définie par l’utilisateur. Toutes les valeurs du vecteur n’ont pas à être renseignées. Le bloc utilise le scalaire N, longueur d’entrée, pour savoir combien d’octets du vecteur d’entrée sont des valeurs reçues et doivent être traités. Le vecteur d’entrée du bloc peut recevoir des paquets de données partiels. Le paquet complet du récepteur peut être découpé dans le temps et envoyé au fur et à mesure que le MCU reçoit les valeurs ; ces blocs reconstituent le paquet avant de le traiter.

Protocole S.BUS

Configuration de l’UART :

Seul le canal Rx est utilisé, avec les paramètres suivants :

100 000 bauds/s
Logique Rx inversée (l’état de repos est le niveau bas), 3,3V
Parité paire
2 bits de stop
Pas de contrôle de flux

Rx utilise un Circular Buffer de 64 octets, avec une priorité d’interruption de 5.

Le bloc UART Rx est échantillonné à 1kHz (1ms). La taille du vecteur de sortie, réglée sur « inherited via internal rule », prend la valeur 10 (pas plus de 10 octets ne peuvent être reçus en 1 ms à 100000 bauds/s avec deux bits de stop).

Dans l’interface graphique du bloc S.BUS, on sélectionne les sorties à décoder et la mise à l’échelle de chaque canal décodé.

Interface utilisateur du bloc Simulink S.BUS

Ce bloc Simulink décode le flux d’entrée S.BUS. On choisit la mise à l’échelle de chaque canal RC de sortie.

Schéma du bloc UART Rx connecté au bloc S.BUS.

Schéma de décodage du S.BUS pour un dsPIC

Schéma de centrage et de mise à l’échelle des canaux S.BUS en sortie dans [-1000 1000]

Les valeurs brutes du S.BUS ne sont ni centrées ni mises à l’échelle par une puissance de 2.

Protocole Smart Port

Le Smart Port (S.Port) utilise un UART dont les broches Rx et Tx sont affectées à la même broche, en logique inversée (1 est le niveau haut). Un seul fil est utilisé, en communication half duplex.

Configuration de l’UART :

57600 bauds/s
Half duplex
Logique Rx et Tx inversée (l’état de repos est le niveau bas), 3,3V
Pas de parité
1 bit de stop
Pas de contrôle de flux

Mise en œuvre :

Rx utilise un Circular Buffer de 32 octets, avec une priorité d’interruption de 5.
Tx utilise un Circular Buffer de 32 octets, avec une priorité d’interruption de 6.

Le bloc Smart Port décode les entrées provenant du récepteur et des autres capteurs connectés au bus à un seul fil.

Si une trame de capteur est reçue, elle est décodée et les valeurs sont disponibles en sortie du bloc.

Lorsqu’une requête du récepteur pour un identifiant de capteur est reçue et que cet identifiant est défini dans l’un des blocs Sensor du modèle, le bloc Smart Port génère la trame du capteur avec les dernières valeurs définies dans le bloc Sensor. Le message est envoyé par un bloc UART Tx.

Protocole F.Port

Title

caption

title

caption

Configuration de l’UART : Les canaux Rx et Tx sont utilisés. Ils sont affectés à la même broche. L’UART est configuré en half duplex.

115200 bauds/s
Half duplex
Logique Rx et Tx inversée (l’état de repos est le niveau bas), 3,3V
Pas de parité
1 bit de stop
Pas de contrôle de flux

Rx utilise un Circular Buffer de 32 octets, avec une priorité d’interruption de 5.

Tx utilise un Circular Buffer de 64 octets, avec une priorité d’interruption de 5.

Ressources

Les protocoles FrSky ne sont pas toujours documentés. Les sites web suivants ont contribué à la compréhension des différents protocoles :

Received Signal Strength Indicator (indicateur de puissance du signal reçu) ↩︎

bloc Sensor

Mon, 01 Jan 0001 00:00:00 +0000

Le bloc ajoute un « paquet » capteur à transmettre à un récepteur par le Smart Port ou le F.Port. Le récepteur envoie le paquet de télémétrie à la radiocommande (RC). Le modèle Simulink doit par conséquent comporter soit un bloc Smart Port, soit un bloc F.Port.

Chaque bloc Sensor déclare la référence du capteur, composée des deux paramètres PhysId et {Address+Offset}. La valeur du capteur est fournie par l’entrée du bloc sous la forme d’un tableau de 4 octets. Plusieurs instances du bloc Sensor peuvent être ajoutées dans un modèle. Deux instances peuvent avoir la même référence de capteur, ce qui convient à un capteur qui envoie plusieurs paquets de valeurs différentes (voir le capteur FrSky FVLSS ou GPS).

Chaque instance du bloc ajoute un tampon de 4 octets qui stocke la valeur du capteur, mise à jour à l’exécution du bloc. Le temps d’échantillonnage du bloc définit la cadence de mise à jour du tampon interne.

Le comportement diffère entre les protocoles Smart Port et F.Port :

Comportement avec le Smart Port

Le récepteur interroge (ping) l’électronique connectée au Smart Port pour une référence de capteur donnée. Lorsqu’un capteur donné est interrogé, il doit répondre en fournissant ses 4 octets de valeur dans un délai de 3 ms.

Si plusieurs instances du bloc Sensor utilisent la même référence de capteur (PhysId, Address+Offset), les paquets de données de chaque bloc sont envoyés les uns après les autres.

Si un identifiant de capteur donné est interrogé deux fois sans que son bloc (aucun de ses blocs, s’il y en a plusieurs) n’ait été mis à jour entre-temps, le même contenu est renvoyé.
Si un bloc Sensor est mis à jour alors que son contenu précédent n’a pas encore été envoyé, la mise à jour est sans effet et la nouvelle valeur est perdue.

Comportement avec le F.Port

Le contrôleur unique connecté au F.Port envoie une valeur de capteur à chaque paquet de canaux RC reçu. Le capteur à envoyer dépend uniquement du contrôleur, qui peut envoyer un capteur quelconque.

Chaque mise à jour d’un bloc Sensor ajoute le capteur dans une file FIFO de demandes d’envoi de capteurs. Une seule demande par instance de bloc Sensor peut être présente dans cette FIFO.

Si un bloc Sensor est mis à jour alors que sa valeur précédente n’a pas encore été envoyée, c’est-à-dire que sa demande d’envoi est toujours dans la FIFO, la mise à jour est sans effet et la nouvelle valeur est perdue.

Contrairement au Smart Port, un capteur ne peut pas être envoyé deux fois sans avoir été mis à jour entre-temps, car le capteur est placé dans la FIFO des demandes d’envoi au moment de sa mise à jour.

pour le capteur correspondant La cadence de mise à jour du bloc est choisie par l’utilisateur final. dont la valeur sera envoyée au récepteur. Le récepteur envoie ensuite l’identifiant du capteur et les valeurs correspondantes à la radiocommande par télémétrie.

La communication avec le récepteur peut utiliser soit le Smart Port, soit le F.Port.

Le PhyId du capteur, l’APPID et la variante d’offset d’APPID sont définis dans le bloc. Le champ PRIM doit être positionné à 0X10 pour un capteur. L’unité de la valeur du capteur est définie dans le bloc. L’entrée du bloc est le codage sur 4 octets de la valeur du capteur.

Pilote automatique d'avion à voilure fixe basé sur un modèle Simulink

Sun, 19 May 2019 00:00:00 +0000

Un pilote automatique 16 bits conçu avec Simulink et des outils de prototypage rapide de commande

Motivation

Il est désormais aisé de construire une plateforme destinée à évaluer différentes boucles de commande de pilote automatique, grâce aux nombreux composants à faible coût disponibles. En voici quelques-uns :

Centrale inertielle (IMU) 10 DoF : (~$5\ $$),
Carte GPS : (~$10\ $$),
Tube de Pitot (sur mesure) : (~$20\ $$),
Carte microcontrôleur : dépend de la carte ; repose sur un microcontrôleur à $\approx 5\ $$,
Plateforme avion : de $60$ à $120\ $$ servos et moteurs inclus.
Quelques éléments de radiocommande sont également nécessaires :
- récepteur
- télécommande
- batterie
quelques éléments optionnels pour l’enregistrement de données, la télémétrie, la caméra…

Différences avec les pilotes automatiques existants

De nombreux pilotes automatiques prêts à l’emploi existent et donnent de bons résultats. En voici quelques-uns :

Ardupilot
PX4
iNav
LibrePilot
Paparazzi.
D’autres sont listés dans le comparatif de DroneTrest).

De manière générale, leurs paramètres internes peuvent être réglés. Cependant, l’insertion d’une boucle de commande personnalisée dans un tel pilote automatique suppose de comprendre la structure du code sous-jacent. Même bien documenté, celui-ci comporte des centaines de fonctions C à examiner avant de pouvoir entreprendre la moindre modification. Une boucle de commande personnalisée peut ne pas s’intégrer dans la structure existante. Il peut être souhaitable de mettre en œuvre un correcteur plus avancé que les PID existants, utiliser une autre fréquence d’échantillonnage, etc.

Il est parfois plus rapide de démarrer un nouveau projet que de réutiliser un projet avancé préexistant. Le pilote automatique présenté utilise une approche de conception basée sur modèle (Model Based Design, MBD) : le code du pilote automatique est généré à partir d’un unique modèle Simulink. Tout se trouve dans le diagramme, de la gestion bas niveau des capteurs jusqu’à la synthèse du correcteur. Cette approche MBD est également appelée prototypage rapide de commande (Rapid Control Prototyping, RCP).

La boucle de commande du pilote automatique utilise des blocs mathématiques standard. La couche bas niveau est assurée par le blockset Microchip, qui gère les périphériques du microcontrôleur. Le blockset UxV donne un accès simple au GPS, à la radiocommande (S.BUS), aux protocoles F.Port et Smart Port, ainsi qu’à la messagerie MAVLink, y compris les protocoles de points de passage (Way Point) et de paramètres. Un tel modèle Simulink permet d’« entrer » dans le projet de manière graphique. Il permet de simuler des parties du système à partir d’un avion simulé ou à partir de valeurs préalablement enregistrées lors d’un vol réel, ce qui est utile pour concevoir des algorithmes de fusion de capteurs avec anticipation (feed-forward).

Une autre différence essentielle est l’utilisation d’un microcontrôleur 16 bits, alors que les autres pilotes automatiques utilisent des microcontrôleurs 32 bits. Les dsPIC 16 bits disposent de toutes les ressources nécessaires grâce à leur architecture efficace, qui gère aisément les nombreux périphériques utilisés (UART, I2C, Output Compare, Input Capture…).

Signalons toutefois qu’une démarche de conception basée sur modèle similaire, utilisant un microcontrôleur dsPIC, a été développée à l’UCSC par le Pr G.H. Elkaim dans un projet nommé SLUG. Leur conception est indépendante de celle présentée ici. Le projet original mené par M.I. Lizarraga [SLUG] (https://slugsuav.soe.ucsc.edu/) est disponible en ligne. La version SLUG II s’appuie sur le même outil que celui utilisé ici pour cibler le dsPIC : le blockset pour microcontrôleurs Microchip (gratuit).

Liste du matériel

Plusieurs configurations matérielles ont été évaluées. Voici une sélection de composants ayant donné des résultats satisfaisants.

plateforme du pilote automatique

Volantex Firstar 1600 avec la télécommande Qx7.

Avion radiocommandé : Volantex Firstar 1600 avec moteurs et servos d’origine (Bixler 2 et Ranger 1600 sont des plateformes alternatives)
Télécommande : FrSky QX7
Récepteur : FrSky XSR-M / XSR utilisé soit avec le protocole S.Bus (sortie des voies du récepteur) et Smart Port (télémétrie), soit avec le protocole F.Port qui combine S.Bus et Smart Port et économise un périphérique UART du microcontrôleur. Chaque protocole n’utilise qu’un seul fil, par conséquent une liaison UART en half-duplex. Le module UART du dsPIC permet de regrouper Tx et Rx sur une seule broche.
Microcontrôleur : dsPIC 33EP sur une carte AUAV V3. Un capteur de mouvement externe est utilisé à la place des capteurs intégrés à l’AUAV3. Une petite carte capteur équipée d’un circuit récent se fixe plus facilement et rigidement près du centre de gravité (CG), ce qui réduit les vibrations. Une carte sur mesure basée sur un dsPIC pourrait remplacer la carte AUAV3, devenue difficile à se procurer. L’UDB5 mini est similaire et reste disponible.
Capteur IMU : Gy-91 (10 DoF avec 3 accéléromètres, 3 gyromètres, 3 magnétomètres et un baromètre). Fixé rigidement près du CG de l’avion. Un bus I2C relie les capteurs au microcontrôleur.
Tube de Pitot :
- Un tube intérieur et un tube extérieur sur lequel quatre trous sont percés latéralement.
- Conditionnement du signal : le capteur de pression du tube de Pitot (MP3V 5004 DP) est lu par un convertisseur ADC MCHP qui intègre un amplificateur analogique. La pression convertie est envoyée au microcontrôleur par le bus I2C. Voir la page construction et test.
GPS : basé sur un module $\mu$blox M8N offrant jusqu’à 10 Hz de rafraîchissement, avec des résultats satisfaisants par rapport aux autres modules du marché.
Enregistreur de données : carte OpenLager pour l’enregistrement sur carte SD. Elle permet d’enregistrer en continu le flux de sortie d’une UART à une vitesse allant jusqu’à 2 470 000 bauds (bien supérieure aux 115 200 bauds que l’enregistreur OpenLog ne peut pas suivre).
Liaison radio : module radio de type 3DR Sik pour la télémétrie MAVLink (attitude de l’avion, position, points de passage et réglage des paramètres) avec la station sol qgroundcontrol qui fonctionne sur la plupart des plateformes (PC, Android, Windows, Linux).
Caméra d’action : RunCam2 pour filmer l’avion et ses gouvernes depuis le dessus ; on observe ainsi le comportement du pilote automatique en fonctionnement.

Électronique embarquée. Une des premières configurations destinées à évaluer divers capteurs. Éléments utilisés : récepteur X8R, carte de distribution PDB-XPM, enregistreur de données sur SD OpenLager, microcontrôleur dsPIC 16 bits AUAV3 avec capteurs (MPU6050), carte IMU 1, carte IMU 2, capteur de pression MP3V5004DP pour le tube de Pitot, GPS1, GPS2, batterie LiPo 3S 2200 mAh, émetteur Qx7.

Résultats

Un correcteur par modes glissants a été évalué sur les axes de tangage et de roulis, selon deux modes :

Commande de la vitesse angulaire de l’avion (consigne de vitesse angulaire donnée par la télécommande)
Commande de l’angle d’attitude de l’avion (consigne d’angle donnée par la télécommande)

La charge moyenne du processeur était de 7 à 8 % sur un dsPIC 33EP cadencé à 70 MIPS. Elle inclut l’algorithme d’estimation de l’IMU, la boucle de commande du pilote automatique et toutes les tâches de bas niveau (gestion de divers protocoles (I2C, NMEA pour le GPS, F.Port, MAVLink) et enregistrement des données capteurs à 1 kHz via une UART configurée à 2 470 000)

Le dispositif a été éprouvé par vent fort. Il met en évidence une robustesse satisfaisante malgré le faible nombre de paramètres réglés jusqu’ici (lien vidéo en haut de page).

L’estimation de la vitesse air par le tube de Pitot a été validée en prenant la vitesse GPS comme référence (ici).

L’estimation de la vitesse et de la direction du vent, basée sur la différence entre les mesures de vitesse GPS et du tube de Pitot en tenant compte de l’orientation de l’avion, a été validée.

L’étalonnage automatique du décalage et du gain des axes du magnétomètre a été validé. Une fois en vol, les perturbations magnétiques près du sol sont négligeables. Un algorithme détermine automatiquement si l’étalonnage peut être affiné avec les données courantes (à partir de données de vol standard, sans looping ni tonneau).

Prochaines étapes

Réduire le broutement (chattering) sur les ailerons lorsque la commande par modes glissants est activée.

Valider en vol le réglage des paramètres via le protocole MAVLink.

Mettre en œuvre le guidage automatique de l’avion, à l’aide de points de cheminement (waypoints) MAVLink.

Contenu du site

Faute de temps, il n’est pas possible de rédiger une description complète du projet comme initialement prévu. Les parties les plus pertinentes seront publiées.

Idées à développer :

IMU
Tube de Pitot
Estimation du vent combinant la vitesse sol GPS et la vitesse air du tube de Pitot
Blocs UxV, dont les blocs et fonctionnalités GPS, radiocommande et MAVLink
Étalonnage automatique des magnétomètres

TP INSA - Commande temps réel d'un moteur DC / PMSM

Sat, 01 Dec 2018 00:00:00 +0000

Commande d’un moteur 24 V (Pravalux 24 V DC) avec la carte MCLV-V2 équipée d’un dsPIC 33EP256MC506. Ce TP s’adresse aux étudiants de 5e année de l’INSA-Lyon.

Le sujet du TP est disponible à l’adresse : https://rtdc.ctrl-elec.fr/.

Les diapositives présentent les adaptations nécessaires pour passer d’un modèle Simulink de simulation (ou dSPACE) à un modèle Simulink ciblant un microcontrôleur. Deux sujets sont abordés :

Ordonnancement temps réel / analyse de la charge du processeur
Types de données en virgule fixe

2021 : le TP sur dSPACE n’étant pas envisageable en salle à cause de la pandémie de Covid-19, il a été remplacé par un TP à domicile sur des cartes MCLV-2 envoyées aux étudiants. Le sujet du TP est disponible à l’adresse : https://rcp.ctrl-elec.fr/