INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
En particulier, la localisation S_LOC de sources sonores du signal sonore capté sc permet de déterminer la localisation d’une ou plusieurs sources sonores dont respectivement le ou les signaux sonores diffusés sd composent le signal sonore capté sc. Notamment, la localisation S_LOC utilise le ou les signaux sonores captés complémentaires {sc + n } n permettant ainsi d’améliorer la précision de la localisation l(sd) ainsi déterminée. En particulier, la localisation déterminée l(sd) est la distance entre la source sonore et un capteur sonore effectuant la capture sonore S_CPT, voire la position relative de la source sonore par rapport au capteur sonore (notamment sous la forme de coordonnées centrées sur le capteur sonore, telles que des coordonnées polaires : distance, angle azimuth, et éventuellement angle polaire, ou des coordonnées cartésiennes : abscisse, ordonnée, et éventuellement la cote ou hauteur), voire la position de la source sonore dans un système générique : par exemple coordonnées GPS.
En particulier, la prédiction S_PRD du signal sonore capté sc estime une évolution du signal sonore capté sc suite à l’instant de capture sonore. La prédiction S_PRD fournit des données prédites pps telles que : soit un signal sonore prédit à partir duquel un ou plusieurs paramètres prédits du signal sonore capté sont déterminés, soit directement un ou plusieurs paramètres prédits du signal sonore capté sc. Notamment, la prédiction S_PRD permet d’estimer un ou plusieurs des paramètres prédits pps suivants : s’il s’agit d’un signal sonore continue ou répétitif , la fréquence d’apparition du signal sonore capté fap(sc), la durée prédite du signal sonore Tp(sc), etc. Eventuellement, pour effectuer une prédiction sur le signal sonore capté sc, la prédiction S_PRD utilise au moins une des données suivantes : - le résultat ps de l’analyse sonore S_NZ, - le signal sonore reconnu sr fournit par la reconnaissance sonore S_RCG.
En particulier, la détection de contexte de modification de position d’équipement domestique CNX_DTC analyse le contexte en fonction du signal sonore capté sc, en particulier en fonction d’au moins une données parmi les suivantes : - le signal sonore capté sc fourni par la capture sonore S_CPT ; - le ou les signaux sonores complémentaires captés {sc + n } n fourni par la ou les captures sonores complémentaires S_CPT + , {S_CPT + n } n ;
- le résultat ps de l’analyse sonore S_NZ ; - le signal sonore reconnu sr fournit par la reconnaissance sonore S_RCG ;
- au moins une localisation l(sd) déterminée par la localisation de source sonore S_LOC ;
- des données prédites pps relatives au signal sonore capté sc fournies par la prédiction S_PRD.
L’analyse de contexte effectuée par la détection de contexte de modification de position d’équipement domestique CNX_DTC permet notamment d’estimer la situation environnementale ES_EST (non illustrée): nuisance sonore, météo, etc. Ainsi la détection de contexte CNX_DTC permet de déclencher une modification de position d’équipement domestique si la situation environnementale estimée répond à certaines conditions de modification de position d’équipements domestiques (CND_VRF).
Selon une option de réalisation, ledit arbre d’entrée est coaxial audit arbre de sortie.
Selon une configuration, ledit arbre d’entrée et/ou ledit arbre de sortie est coaxial avec ladite couronne.
Conformément à un mode de réalisation, ledit arbre d’entrée et/ou ledit arbre de sortie est à l’extérieur de ladite couronne.
Selon une mise en œuvre, ladite première source d’entraînement est un pédalier, et la transmission variable est agencée dans ledit pédalier.
Avantageusement, ledit véhicule terrestre est un deux-roues ou un tricycle, notamment une bicyclette.
Selon un aspect, ledit véhicule terrestre est à assistance électrique, comprenant un groupe motopropulseur formé par ladite machine électrique et ladite transmission variable.
La illustre une vue en coupe d’une transmission variable selon un premier mode de réalisation de l’invention.
Les figures 2A à 2D illustrent différentes variantes de réalisation d’une transmission variable selon l’invention.
Les figures 3A à 3C illustrent différentes variantes de réalisation d’une transmission variable selon l’invention.
Les figures 4A à 4D illustrent différentes variantes de réalisation d’une transmission variable selon l’invention.
Les figures 5A et 5B illustrent différentes variantes de réalisation d’une transmission variable selon l’invention.
La présente invention concerne une transmission variable. En d’autres termes, la présente invention concerne une transmission du type transmission à variation continue CVT ou transmission infiniment variable IVT.
Selon l’invention, la transmission comporte : Un arbre d’entrée, apte à être connecté à un entraînement par exemple une machine électrique ou un pédalier, Au moins un galet d’entrée conique ou tronconique, chaque galet d’entrée est entraîné par un axe de galet d’entrée (chaque galet d’entrée est monté sur un axe de galet d’entrée), et chaque axe de galet d’entrée coopère avec l’arbre d’entrée au moyen d’un engrenage (appelé engrenage d’entrée), Un arbre de sortie, apte à entraîner directement ou indirectement une charge, par exemple une roue d’un véhicule, Au moins un galet de sortie conique ou tronconique, chaque galet de sortie entraîne un axe de galet de sortie (chaque galet de sortie est monté sur un axe de galet de sortie), et chaque axe de galet de sortie coopère avec l’arbre de sortie au moyen d’un engrenage (appelé engrenage de sortie), et Une couronne qui coopère par friction avec chaque galet d’entrée et chaque galet de sortie, la couronne entourant les galets d’entrée et de sortie (on parle de couronne, car c’est la partie intérieure de la couronne qui coopère avec chaque galet d’entrée et chaque galet de sortie).
- démarrer l’application des premières données primaires sur les premières entrées des premiers multiplexeurs puis, après un nombre prédéfini de cycles d’horloge, démarrer l’application des deuxièmes données primaires sur les deuxièmes entrées des premiers multiplexeurs ;
- piloter les premiers multiplexeurs de sorte que la chaîne de calcul, simultanément, termine une multiplication du premier vecteur primaire par chacun des vecteurs secondaires et débute une multiplication du deuxième vecteur primaire par chacun des vecteurs secondaires.
On propose de plus un circuit de calcul tel que précédemment décrit, les vecteurs secondaires formant une matrice, la séquence cyclique prédéfinie comportant des cycles comprenant chacun une première phase au cours de laquelle les séries de données secondaires comprennent un nombre croissant de composantes de lignes ou de colonnes successives de la matrice, une deuxième phase au cours de laquelle les séries de données secondaires comprennent un nombre constant de composantes de lignes ou de colonnes successives de la matrice, et une troisième phase au cours de laquelle les séries de données secondaires comprennent un nombre décroissant de composantes de lignes ou de colonnes successives de la matrice.
On propose de plus un circuit de calcul tel que précédemment décrit, dans lequel le circuit de calcul comprend plusieurs chaînes de calcul et un multiplexeur additionnel ayant une ou des entrées reliées à un ou des accumulateurs d’un ou de blocs de calcul de la même chaîne de calcul et/ou d’une autre chaîne de calcul.
On propose de plus un circuit de calcul tel que précédemment décrit, comprenant une pluralité de structures de calcul comprenant chacune une pluralité de chaînes de calcul, les structures de calcul étant arrangées selon une architecture pipeline.
On propose de plus un circuit de calcul tel que précédemment décrit, chaque structure de calcul étant agencée pour effectuer des produits de convolution pour une couche de convolution distincte d’un modèle de réseau de neurones.
On propose de plus un composant électronique dans lequel est réalisé le circuit de calcul tel que précédemment décrit.
On propose de plus un composant électronique tel que précédemment décrit, le composant électronique étant un FPGA.
On propose de plus un composant électronique tel que précédemment décrit, le FPGA comprenant des blocs DSP, chaque bloc de calcul étant réalisé dans un bloc DSP.
On propose de plus un composant électronique tel que précédemment décrit, le circuit de calcul comprenant au moins une structure de calcul présentant une architecture matricielle comprenant une pluralité de chaînes de calcul formant des lignes de l’architecture matricielle, le circuit de calcul comprenant des blocs DSP dans chacun desquels sont réalisés deux blocs de calcul de deux lignes successives.
On propose de plus un composant électronique tel que précédemment décrit, le composant électronique étant un ASIC.
la illustre un produit de convolution de matrices réalisé dans une architecture systolique ;
la représente le produit de convolution d’un tenseur d’entrée par un masque ;
la représente un exemple de bloc DSP ;
Selon l’exemple considéré, le client DNS 41 peut notamment émettre une ou plusieurs requêtes DNS pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », notées HB, en tenant compte de la valeur indiquée dans le champ « EPOCH » de la réponse reçue. Par exemple, le champ « EPOCH » comporte une information de récurrence indiquant une périodicité d’envoi T1 des requêtes HB. Ainsi, une première requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l’instant T0+T1, une deuxième requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l’instant T0+2*T1, une troisième requête HB pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » peut être émise à l’instant T0+3*T1, etc.
De telles requêtes HB (« HeartBeat ») permettent de signaler au serveur de confiance 42 la présence d’une association active avec un client DNS 41.
Selon l’exemple considéré, le client DNS 41 peut notamment calculer un condensé des données de vérification véhiculées dans le champ « CHALLENGE » de la réponse reçue lors de la phase d’activation PER ASPERA. Un tel condensé peut notamment être inséré dans le champ « NONCE » de la requête HB qui contient l’option WADE.
Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (412) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE », à l’instant T0+T1. A réception de la première requête HB (412), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes, i.e. permettent d’identifier le même équipement (src@=@1). Si ce n’est pas le cas, une anomalie est détectée. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des données de vérification stockées par le serveur de confiance 42 (telles que consignées dans le champ « CHALLENGE » dans la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (par exemple procéder au calcul « Hash (CHALLENGE) » où Hash désigne une fonction de hachage correspondant à celle appliquée par le client DNS 41 pour générer le condensé des données de vérification (par exemple « Secure Hash Algorithms (SHAs) » décrits dans le document RFC 6234 « US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) » de mai 2011) et vérifier qu’il est égal au condensé transmis dans le champ « NONCE ». Si ce n’est pas le cas, une anomalie est détectée par le serveur de confiance 42. Le serveur de confiance 42 peut également vérifier si l’information de récurrence spécifiée dans le champ « EPOCH » est respectée. Si ce n'est pas le cas, une anomalie est détectée. En variante, l’indication de la fonction « hash » à utiliser par un client DNS peut être communiquée à l’aide de l’option WADE. Pour ce faire, un bit « I » est défini à cet effet parmi les bits « unassigned » décrits dans la . Quand le bit « I » est positionné à « 1 », l’identité de la fonction « hash » est renseignée dans le corps de l’option WADE (par exemple SHA2-256).
Le client DNS 41 peut ensuite émettre une deuxième requête HB (413) pour la résolution du nom de domaine indiqué dans le champ TARGET_HB_FQDN, comportant une preuve d’intégrité dans le champ NONCE, à l’instant T0+2T1. Le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la deuxième requête HB (src@) sont cohérentes (src@=@1), que le condensé des données de vérification (Hash (CHALLENGE)) est égal au condensé transmis dans le champ NONCE et que l’information de récurrence contenue dans le champ « EPOCH » est respectée.
Le client DNS 41 peut émettre une troisième requête HB (414) et ainsi de suite.
Dans l’exemple illustré par la , aucune anomalie n’est détectée.
Dans un mode de réalisation particulier, les informations communiquées lors de l’activation du service PER ASPERA peuvent être modifiées à l’initiative du serveur de confiance 42 ou du client DNS 41.
La illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42, avec une demande de modification des données de vérification à l’initiative du client DNS 41.
On considère par exemple que le client DNS 41 émet une requête d’activation en utilisant son adresse @1, et que le serveur de confiance 42 construit une réponse comportant les champs « TARGET_HB_FQDN », « EPOCH » et « CHALLENGE1 » (Activ. PER APSERA 511).
Selon l’exemple illustré par la , le client DNS 41 émet une première requête HB (512) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE1 », à l’instant T0+T1. A réception de la première requête HB (512), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la première requête HB (src@) sont cohérentes. Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE1 » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des données de vérification portées par le champ « CHALLENGE1 ». Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE1)) et vérifier qu’il est égal au condensé transmis dans le champ « NONCE1 ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence spécifiée dans le champ « EPOCH » est respectée.
Le client DNS 41 peut demander à tout moment de modifier les données de vérification (« CHALLENGE1 »). Pour ce faire, le client DNS peut envoyer une deuxième requête HB (513) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN » comportant une preuve d’intégrité dans le champ « NONCE1 », calculé sur la base des données de vérification du champ « CHALLENGE1 ». Pour informer le serveur de confiance 42 que le client DNS 41 demande de nouvelles données de vérification, les bits C et N sont positionnés à « 1 ».
A réception de ce message, le serveur de confiance 42 peut accepter la demande et générer de nouvelles données de vérification, qui sont transmises au client DNS 41 dans une réponse qui contient l’option WADE, dans le champ « CHALLENGE2 » (514).
Le client DNS 41 peut émettre une troisième requête HB (515) pour la résolution du nom de domaine indiqué dans le champ « TARGET_HB_FQDN », comportant une preuve d’intégrité dans le champ « NONCE2 », à l’instant T0+2T1. Une telle preuve d’intégrité est obtenue à partir des nouvelles données de vérification « CHALLENGE2 ». A réception de la troisième requête HB (515), le serveur de confiance 42 peut notamment vérifier que l’adresse source de la requête d’activation (@1) et l’adresse source de la troisième requête HB (src@) sont cohérentes, i.e. permettent d’identifier le même équipement (src@=@1). Le serveur de confiance 42 peut également vérifier que la preuve d’intégrité contenue dans le champ « NONCE2 » de la requête HB est cohérente avec une preuve d’intégrité déterminée localement à partir des nouvelles données de vérification stockées par le serveur de confiance 42 (telles que contenues dans le champ « CHALLENGE2 » de la réponse émise par le serveur de confiance). Notamment, le serveur de confiance 42 peut calculer un condensé des données de vérification (Hash (CHALLENGE2)) et vérifier qu’il est égal au condensé contenu dans le champ « NONCE2 ». Le serveur de confiance 42 peut également vérifier si l’information de récurrence contenue dans le champ « EPOCH » est respectée.
Le client DNS 41 peut émettre une quatrième requête HB (516) et ainsi de suite.
La illustre un exemple de messages échangés entre le client DNS 41 et le serveur de confiance 42, avec une demande de modification des données de vérification à l’initiative du serveur de confiance 42.
Avantageusement, le procédé d’asservissement comporte une localisation de sources sonores du signal sonore capté, la commande générée étant fonction de la localisation de sources sonores du signal sonore capté par rapport à la position d’un équipement domestique.
Avantageusement, le procédé d’asservissement comporte une prédiction d’évolution du signal sonore capté postérieure à l’instant de capture sonore.
Ainsi, lorsque le contexte de modification de position est intermittent, par exemple un bruit intermittent, l’automatisation évitera la succession d’ouverture et de fermeture d’ouvrant, aussi nommé bagotement de l’état de la fenêtre, qui peut être pénible à une personne présente près de la fenêtre ou dans la pièce dans laquelle la fenêtre est située. En outre, une succession d’ouverture et de fermeture pourrait engendrer une usure précoce des pièces de changement de position de la fenêtre (charnière, galet de coulissement, etc.) ce qui est ainsi réduit.
Avantageusement, la commande générée est une commande programmée en fonction d’au moins un paramètre prédit du signal sonore capté.
Ainsi, l’automatisation est mise en œuvre par exemple sur des plages horaires programmées, ou en fonction de valeurs programmées de données captées par exemple, détection de présence et/ou d’absence, une automatisation de la fermeture de fenêtre en cas de nuisance signal sonore sera autorisée uniquement si la température intérieure est dans une plage de température programmée, une automatisation de l’ouverture de la fenêtre à la fin d’une nuisance signal sonore uniquement si aucune pluie n’est détectée, etc.
Avantageusement, le procédé d’asservissement comporte une détection d’un contexte de modification de position d’équipements domestiques en fonction d’un signal sonore capté, la détection d’un contexte de modification de position d’équipements domestiques déclenchant la génération de commande.
Avantageusement, la détection de contexte de modification de position d’équipements domestiques est fonction d’un critère relatif au signal sonore capté parmi les critères suivants : - niveau signal sonore du signal sonore capté, - type de signal sonore capté, - durée prédite du signal sonore capté, - fréquence prédite d’apparition du signal sonore capté.
Avantageusement, la détection de contexte de modification de position est fonction d’au moins un paramètre d’asservissement préconfiguré.
Avantageusement, selon une implémentation de l'invention, les différentes étapes du procédé selon l'invention signal sont mises en œuvre par un logiciel ou programme d'ordinateur, ce logiciel comprenant des instructions logicielles destinées à être exécutées par un processeur de données d’un asservissement et/ou d’un système d’asservissement, notamment un assistant domotique, et étant conçus pour commander l'exécution des différentes étapes de ce procédé.
L'invention vise donc aussi un programme comprenant des instructions de code de programme pour l’exécution des étapes du procédé d’asservissement lorsque ledit programme est exécuté par un processeur.
Un objet de l’invention est également un asservissement de position d’équipements domestiques comportant un générateur de commande en fonction d’un signal sonore capté, la commande générée étant apte à déclencher le contrôle par un actionneur d’un équipement domestique, l’actionneur déplaçant l’équipement domestique dans une position fonction de la commande.
Avantageusement, le générateur de commande est apte à générer plusieurs commandes en fonction d’un signal sonore capté, chaque commande générée étant apte à déclencher le contrôle par un actionneur distinct d’un équipement domestique distinct.
Avantageusement, un équipement domestique est un équipement parmi les suivants : - un ouvrant ; - un réducteur de bruit ; - un dispositif d’annulation d’écho.
Un objet de l’invention est, en outre, un système d’asservissement comportant : - un capteur sonore colocalisé avec un équipement domestique ; - un actionneur de l’équipement domestique apte à modifier la position de l’équipement domestique ; - un asservissement de position d’équipements domestiques apte à générer une commande en fonction d’un signal sonore capté par le capteur, la commande générée étant apte à déclencher le contrôle par l’actionneur de l’équipement domestique, l’actionneur déplaçant l’équipement domestique dans une position fonction de la commande.
Avantageusement, le système d’asservissement comporte plusieurs capteurs sonores colocalisés avec des équipements domestiques distincts, et l’asservissement de position étant apte à générer une commande de contrôle d’un des équipements domestiques colocalisé avec le capteur sonore ayant capté le signal sonore capté en fonction duquel la commande est générée.
Selon un exemple de réalisation, la transmission variable peut être montée dans un carter (par exemple, dans le cadre d’une bicyclette : au niveau du pédalier, ou dans un carter d’un groupe motopropulseur comprenant une machine électrique et la transmission variable). Dans ce cas, les arbres d’entrée et de sortie ainsi que les axes des galets d’entrée et de sortie peuvent être en liaison pivot par rapport au carter, et la couronne peut être en mouvement pivot-glissant par rapport au carter.
Selon un mode de réalisation, chaque galet d’entrée peut être identique (forme et dimensions) à chaque galet de sortie, ce qui favorise le montage ainsi que la fabrication (un seul type de galet conique ou tronconique est alors fabriqué).
Les différentes liaisons (pivot, pivot-glissant, translation) au sein de la transmission variable peuvent être réalisées par tout moyen, notamment par des roulements à billes, glissières à billes, roulements à rouleaux, paliers, etc.
Les figures 2 à 5 illustrent, schématiquement et de manière non limitative, différentes variantes de réalisation de l’invention. Ces figures sont des coupes partielles (tous les composants ne sont pas représentés) selon la coupe AA de la . Sur ces figures, les galets d’entrée et de sortie ne sont pas circulaires, car ils sont dans le plan de coupe AA qui n’est pas perpendiculaire à leurs axes respectifs.
Les figures 2A à 2D illustrent quatre configurations des galets d’entrée et de sortie selon des variantes de réalisation de l’invention. Sur ces figures, seuls la couronne 8, les galets d’entrée 6 et de sortie 10 et leurs axes 5 et 11 sont représentés.
Pour la variante de la figure 2A, la transmission variable comprend un galet d’entrée 6 et un galet de sortie 10. Pour cette variante, le galet d’entrée 6 est diamétralement opposé au galet de sortie 10 au sein de la couronne 8.
Pour la variante de la figure 2B, la transmission variable comprend un galet d’entrée 6 et un galet de sortie 10. Pour cette variante, le galet de sortie 10 est décalé par rapport au diamètre qui passe par le galet d’entrée 6.
Pour la variante de la figure 2C, la transmission variable comprend deux galets d’entrée 6 et deux galets de sortie 10. Pour cette variante, chaque galet d’entrée 6 est diamétralement opposé à un galet de sortie 10.