« SE5 ECEAI/eceai 2024/2025/benmbarek-elqastalani » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (8 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
'''Le 03/09/2024 :''' | |||
- Recherche du sujet | |||
- Installation des logiciels | |||
'''Le 05/09/2024 :''' Nous avons décidé de concevoir un système qui déterminera dans un premier temps la pression dans une balle en chute libre, puis, si on avance bien, prédire la hauteur du deuxième rebond. | |||
Voici la démarche à laquelle nous avons pensé : | |||
[[Fichier:Schema ia1.png|800px|center|Schéma]] | |||
Avec quelques entrainements, nous pourrons calculer la pression. | |||
Le matériel utilisé : | |||
* Raspberry Pi 4 | |||
- | * Nucleo-F401RE | ||
* Capteur de distance Nucleo-53L5A1 | |||
* Accéléromètre (pas pour le moment) (mettre reference) | |||
le | Notre Raspberry communiquera avec la Nucleo par liaison série UART. Elle servira aussi d'interface entre la Nucleo, qui sera entraînée à manipuler les données, et le réseau. | ||
Lors de cette première séance, nous avons aussi configuré l'OS de la Raspberry ainsi que sa connexion à la borne Wi-Fi de la salle. | |||
// utiliser architecture perceptron, une entrée 15 sorties. ( winner takes all concept, ReLu activation func ? ) | |||
Nous avons besoin // | |||
Notre première approche est de proposer un modèle simple de classification. | Notre première approche est de proposer un modèle simple de classification. | ||
La communication entre l'accéléromètre et la nucleo se fait en I2C. | // La communication entre l'accéléromètre et la nucleo se fait en I2C. | ||
Possible Challenges: | // Possible Challenges: | ||
The trajectory of the falling object will almost always be non linear, which introduces new parameters to the equation. | // The trajectory of the falling object will almost always be non linear, which introduces new parameters to the equation. | ||
Need to take in account the weight of the object, the size, the rebound behaviour (ricochet). (Probably need a soft surface in order not to damage the object). | // Need to take in account the weight of the object, the size, the rebound behaviour (ricochet). (Probably need a soft surface in order not to damage the object). | ||
The length of the connection could probably affect the communication ? Would it be possible to store the experience data then feed the model, or should it be real time ? | // The length of the connection could probably affect the communication ? Would it be possible to store the experience data then feed the model, or should it be real time ? | ||
Version actuelle datée du 9 septembre 2024 à 10:11
Le 03/09/2024 :
- Recherche du sujet
- Installation des logiciels
Le 05/09/2024 : Nous avons décidé de concevoir un système qui déterminera dans un premier temps la pression dans une balle en chute libre, puis, si on avance bien, prédire la hauteur du deuxième rebond.
Voici la démarche à laquelle nous avons pensé :
Avec quelques entrainements, nous pourrons calculer la pression.
Le matériel utilisé :
- Raspberry Pi 4
- Nucleo-F401RE
- Capteur de distance Nucleo-53L5A1
- Accéléromètre (pas pour le moment) (mettre reference)
Notre Raspberry communiquera avec la Nucleo par liaison série UART. Elle servira aussi d'interface entre la Nucleo, qui sera entraînée à manipuler les données, et le réseau.
Lors de cette première séance, nous avons aussi configuré l'OS de la Raspberry ainsi que sa connexion à la borne Wi-Fi de la salle.
// utiliser architecture perceptron, une entrée 15 sorties. ( winner takes all concept, ReLu activation func ? )
Nous avons besoin // Notre première approche est de proposer un modèle simple de classification.
// La communication entre l'accéléromètre et la nucleo se fait en I2C.
// Possible Challenges:
// The trajectory of the falling object will almost always be non linear, which introduces new parameters to the equation.
// Need to take in account the weight of the object, the size, the rebound behaviour (ricochet). (Probably need a soft surface in order not to damage the object).
// The length of the connection could probably affect the communication ? Would it be possible to store the experience data then feed the model, or should it be real time ?