je crois qu'il existe des CAN à bus parralèles avec plein d'entrés, cela serait plus simple pour les lires. Je ne suis pas sur qu'une sorte de DMA pour SPI soit si simple et suffisamment petit pour en mettre plein.
Disons qu'une tel carte n'est pas aussi simple que ça du tout. Je voulais signaler aux auteurs du potentiel d'une tel carte fille, en plus si il y a des drivers linux, c'est encore mieux :)
Je me doute bien qu'il y a des cartes filles, je me demandais si il y avait une carte fille avec ce genre d'IOs, car faire ce genre de carte avec des pas fin n'est pas facile du tout.
Les CAN ne s'ajoutent pas à un FPGA, bien qu'il soit possible d'en faire un avec un comparateur externe en plus, ce n'est pas si précis.
C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.
non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.
La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.
là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.
A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.
En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
Le jit de java est du niveau de gcc -o0 ou gcc -o1, des mini optims "à la con" font de gain énorme de performances (genre virer les setter/getter qui ne sont pas inliner !)
Ton programme de preuve pourrait détecter que rien ne borne ton index et donc que tu as potentiellement un trou. Il pourrait déduire des bornes en détectant des tests ou un modulo sur l'élément.
C'est dans ses moments-là, ou il est marrant de constater que diminuer la mémoire dédiés par la VM peut augmenter les performances en rapprochant le déclenchement du GC.
Après, bien sûr, je ne cherche pas à dénigrer ton objectif et toute amélioration est bonne à prendre, mais si tu voyais la qualité générale des codes scientifiques, tu verrais que l’efficacité des algorithmes de résolution et la parallélisation sont des enjeux qui passent bien avant l’optimisation purement au niveau du code.
Il faut comprendre que le code est pourris ou l'inverse ? :)
D'un autre coté, une bonne implémentation peut te fait gagner un facteur 10, mais je suis d'accord qu'un bon algo peut aller bien au delà.
Je ne parle pas des intel à base de gpu non intel.
ATI je me rappelle les triangles qui clignotent, les plantages quasi immédiat. Mais souvent les problèmes sont dans les détails : impossible de passer en veille, ventilo non géré et à fond.
Si je veux jouer j'utilise un ordinateur ayant un OS de console de jeu : un PC windows.
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
je crois qu'il existe des CAN à bus parralèles avec plein d'entrés, cela serait plus simple pour les lires. Je ne suis pas sur qu'une sorte de DMA pour SPI soit si simple et suffisamment petit pour en mettre plein.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Disons qu'une tel carte n'est pas aussi simple que ça du tout. Je voulais signaler aux auteurs du potentiel d'une tel carte fille, en plus si il y a des drivers linux, c'est encore mieux :)
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Le problème c'est fabriquer la carte fille qui va avec, la fabriquer soi-même n'est pas simple.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 1.
Je me doute bien qu'il y a des cartes filles, je me demandais si il y avait une carte fille avec ce genre d'IOs, car faire ce genre de carte avec des pas fin n'est pas facile du tout.
Les CAN ne s'ajoutent pas à un FPGA, bien qu'il soit possible d'en faire un avec un comparateur externe en plus, ce n'est pas si précis.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Tu sais combien ça coute un FPGA avec 1000 ios ? Et le prix de la carte pour le poser dessus ?
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
Si tu divises par 2 ton salaire en suisse combien tu dois gagner aux US ! :)
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 3.
C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
"La première sécurité est la liberté"
# Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.
non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
obj.getVoiture().getFirstRoue()
là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ensuite, l'inline par le compilo devrait régler les problèmes de perf.
C'est le "devrait" le problème : le jit de sun ne le fait pas.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
A court terme, c'est parfaitement inutile.
A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.
En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ce genre d'optimisation de "delayed initialisation", se fait aussi à coup de pointeur nul que l'on teste avant utilisation.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Le jit de java est du niveau de gcc -o0 ou gcc -o1, des mini optims "à la con" font de gain énorme de performances (genre virer les setter/getter qui ne sont pas inliner !)
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
ocaml ?
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ton programme de preuve pourrait détecter que rien ne borne ton index et donc que tu as potentiellement un trou. Il pourrait déduire des bornes en détectant des tests ou un modulo sur l'élément.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
euh...
"La première sécurité est la liberté"
[^] # Re: porosité aux virus
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
C'est dans ses moments-là, ou il est marrant de constater que diminuer la mémoire dédiés par la VM peut augmenter les performances en rapprochant le déclenchement du GC.
"La première sécurité est la liberté"
[^] # Re: Marre des captcha
Posté par Nicolas Boulay (site web personnel) . En réponse au journal CAPTCHA. Évalué à 2.
Et avec 10 questions ? :)
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
J'ai fait beaucoup de C, si tu ne fais pas de gros calcul, je te conseil de passer à ocaml. C'est incroyable le gain de productivité.
"La première sécurité est la liberté"
[^] # Re: Pi
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cherche exemple d'expression de calcul lourd. Évalué à 2.
Mais si la microoptimisation est gratuitement faite par le compilateur ?
"La première sécurité est la liberté"
[^] # Re: Pi
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cherche exemple d'expression de calcul lourd. Évalué à 2.
Après, bien sûr, je ne cherche pas à dénigrer ton objectif et toute amélioration est bonne à prendre, mais si tu voyais la qualité générale des codes scientifiques, tu verrais que l’efficacité des algorithmes de résolution et la parallélisation sont des enjeux qui passent bien avant l’optimisation purement au niveau du code.
Il faut comprendre que le code est pourris ou l'inverse ? :)
D'un autre coté, une bonne implémentation peut te fait gagner un facteur 10, mais je suis d'accord qu'un bon algo peut aller bien au delà.
"La première sécurité est la liberté"
[^] # Re: L'argent
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 3.
Je ne parle pas des intel à base de gpu non intel.
ATI je me rappelle les triangles qui clignotent, les plantages quasi immédiat. Mais souvent les problèmes sont dans les détails : impossible de passer en veille, ventilo non géré et à fond.
Si je veux jouer j'utilise un ordinateur ayant un OS de console de jeu : un PC windows.
"La première sécurité est la liberté"
[^] # Re: L'argent
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 3.
Surtout le driver intel est libre, et c'est plus simple à gérer (pour les anciens modèles).
"La première sécurité est la liberté"