Aller au contenu


Contenu de H.Cou29

Il y a 25 élément(s) pour H.Cou29 (recherche limitée depuis 04-avril 13)


#9399 Siège de simulateur de vol (suite)

Posté par H.Cou29 sur 20 juillet 2007 - 09:39 dans Hack mod customisations et autres modifications

Je mettrais des photos en octobre.
Bonnes vacances à tous.



#9384 Siège de simulateur de vol (suite)

Posté par H.Cou29 sur 18 juillet 2007 - 10:43 dans Hack mod customisations et autres modifications

Bonjour à tous,

C'est la suite du post simulateur de vol qui était dans la rubrique "général".

Je commence seulement à y voir un peu plus clair dans le fonctionnement des moteurs pas à pas.
J'ai commencé par griller un driver à base de L297 et L6203, j'ai poussé un peu trop le courant.
J'ai récupéré du club robots de l'INSA de Lyon un driver à base de L6208 pilotés par un 16F877A, ce driver fonctionne bien mais a été réalisé avec des composants cms, trop petits composants pour bricoler.
Je viens de refaire des cartes à base de bons vieux composants, à une seule face (moyennant quelques straps), et répondant parfaitement à mon cahier des charges:
une carte alim avec gestion des inters de mise en route et gestion des fins de course,
une carte réception à base de 18F4550 pour la gestion de la réception des données par USB et retransmission par I2C, avec afficheur,
deux cartes driver moteur à base de 16F877 et de L6208 .
les driver peuvent recevoir des informations externes, et ont un système de réduction de courant en maintient de position.
En fait mes cartes driver sont à refaire car pour la programmation j'ai besoin de davantage de mémoire et il me faut également des 18F4550. (Tant que je ne me sert pas de l'I2C je peux remplacer le 877 par le 4550 et je peux continuer mes essais).

Les caractéristiques des moteurs pas à pas dépendent du driver, ceux que l'on peut trouver dans l'industrie seraient capable de performances bien supérieures à celles que j'obtiens, j'en suis donc amené à pousser systématiquement la vitesse et le couple jusqu'à la perte de pas, ce qui me permet d'en déduire une courbe de couple-vitesse à ne pas dépasser.

Coté programmation, on m'a fait un programme qui récupère les valeurs des angles dans l'avion du jeu du pc et que j'affiche sur ma carte réception.
Il me faudra donc trier, traiter et les envoyer sur les pic des drivers.

Pour générer les rampes de montée en vitesse, plutôt que de faire à chaque interruption le calcul du temps de pas suivant, j'ai préféré enregistrer une table de 200 valeurs pour les 200 pas, la programmation s'en trouve beaucoup plus simple moyennant suffisamment de ram d'où le remplacement des 877 par des 4550.

Actuellement, j'ai un programme qui me fait monter, descendre puis remonter au point de départ, je teste le domaine sans perte de pas . Quand ça marche , c'est très agréable.
En vitesse je passe de 0 à 100mm/s en 0.1s, c'est la moitié de ce que je pensais.

Il reste la programmation de l'asservissement, je sais ce que je vais essayer mais il faut mettre en forme.

Comme matériel, j'ai un EasyPIC4 et je programme avec mikroC.

Tout cela est finalement beaucoup plus long que je ne l'avais imaginé.



#9175 Siège de simulateur de vol (suite)

Posté par H.Cou29 sur 12 février 2007 - 11:28 dans News dans le domaine de la robotique

Bonsoir,

Autant j'arrive à m'y retrouver et à programmer en C pour le pic, autant je n'arrive pas à suivre les fichiers source d'un programme en C++.

Pour l'instant, après avoir vérifié que je savais recevoir des octets sur le µC , la dll qui a été faite, qui est dans le logiciel du jeu, et qui devrait m'envoyer des données n'arrive pas à ouvrir le port com1. Mon collègue fait ça très bien, il y a des fichiers txt Debug qui indiquent tout ce qui doit ce passer, mais qui pour l'instant indiquent unable open com1.
Je lui ai suggéré de remplacer la dll par un exe afin de dissocier les problèmes. Je ne suis pas inquiet.

Si vous aviez à faire un programme pour envoyer quelques octets sur le port com1, quelle routine élémentaire serait utilisée. J'ai déjà posé la question à plusieurs programmeurs et ils m'ont trouvé des documents plus monstrueux les uns que les autres pour envoyer des trames...mini 10 octets (5 int, ils ne connaissent pas plus petit).

SVP, pour quelques octets y a pas quelque chose de plus adapté à ce dont on a besoin ?



#9134 Siège de simulateur de vol (suite)

Posté par H.Cou29 sur 11 février 2007 - 03:47 dans News dans le domaine de la robotique

Bonjour à tous,

J'ai un soucis de transfert par le port série.
Je reçois bien avec le pic ce que je m'envoie avec l'hyperterminal de XP.
Le problème se situe en amont pour l'envoie des données. Le collègue qui s'occupe de récupérer les données dans le jeu via une dll, programme en C++ et fait appel à des routines capable d'envoyer plein de choses, alors que pour nos applications, on a besoin que de quelques octets. Le mieux n'étant pas toujours l'ami du bien, existe-t-il des routines adaptées à nos besoins.
Merci et amitiés.



#8537 Siège de simulateur de vol (suite)

Posté par H.Cou29 sur 04 janvier 2007 - 08:06 dans News dans le domaine de la robotique

Bonsoir,

En fait, j'aurais du vous envoyer celle ci en premier mais, jusqu'à hier soir, je ne savais pas programmer les afficheurs.

Image IPB

Avec un programme de montée descente pour 5000 pas, le voila déjà en action.

Image IPB

Je suis assez satisfait que ça fonctionne.

A+ pour la suite.
Amitiés.



#8514 Siège de simulateur de vol (suite)

Posté par H.Cou29 sur 02 janvier 2007 - 10:22 dans News dans le domaine de la robotique

Bonjour et bonne année à tous,

Il y a quelques mois je vous avais présenté mon projet de siège simulateur de vol et, comme j'avais obtenu sur ce forum de précieux renseignements, je vous ai fait un état des lieux en ce début d'année.

Rappel: il s'agit d'un siège mobile en tangage et roulis dont les mouvements doivent être asservis sur ceux de l'horizon artificiel d'un aéronef (orienté hélicoptère) dans un logiciel de vol FLYII.
Partant avec l'idée qu'il fallait rester en numérique, j'ai opté pour des moteurs pas à pas.
Le projet final comprendra 3 micro-contrôleurs, un pour pour la receptions et le traitement des données issues du pc et un pour le contrôle de chaque axe.

Image IPB

A part la structure bois que je dois refaire, la partie mécanique est pratiquement terminée.

Pour la partie électronique, j'ai d'abord acheté, chez Selectronic, une carte d'alimentation de moteur pas à pas avec sa pochette de composants, réalisée à partir d'un L297 et de deux L6203, je l'ai cablée et essayée sur une platine d'essais, et avec un générateur de signaux carrés .
Ca a fonctionné du premier coup, heureux présage.
Comme il y a un risque de casse, il me faut des fins de course musclées, c'est à dire qui me coupent la puissance d'alimentation des moteurs par l'intermédiaire de relais . Ces fins de course ne devraient servir qu'en cas de défaillance du logiciel qui en utilise d'autres, magneto-résistant, montés sur les vérins. Pour des essais mieux vaut tout prévoir.

Le moteur est alimenté en 48v, les fins de course des vérins entre 10 et 30v, le circuit de puissance et le kit de développement en 7v car ils sont tous les deux munis d'un régulateur pour le 5v.
A partir du 48v j'ai un régulateur qui me fait du 7v pour alimenter la carte puissance et le kit (il disparaîtra dans la version finale) ainsi qu'un autre qui me fait du 24v qui sert à la fois aux relais de fin de course de puissance ainsi qu'à ceux des vérins dont les signaux sont ramenés en 5v par opto-coupleur.

J'en suis à la troisième mouture qui va me permettre de relier la carte puissance et sécurité à un kit de développement Easy4, et ainsi, à pouvoir commencer à tester une commande programmée à partir du 16F877 livré avec le kit.

Image IPB

Je n'ai pas programmé depuis 20 ans et c'était en basic. Je me suis mis au C. Je pensais naïvement qu'il n'y avait qu'un seul et même jeu d'instructions mais que nenni !! chaque compilateur dédié aux uc ne comprend que ses propres instructions qu'il faut encore aller chercher dans des exemples et, comme il y a souvent plusieurs façon différentes d'arriver à un même résultat, c'est pas facile de s'y retrouver.
Jai simplement essayé de reproduire les exemples que j'avais.
J'ai commencé avec BoostC, les programmes étaient acceptés mais ne fonctionnaient pas sur le uc.
J'ai essayé le PCWH cité par C. Tavernier car dans son ouvrage, il s'est donné la peine de fournir un jeu d'instructions clair, sans doute n'avais-je pas la bonne version car je ne suis arrivé à rien mais il est vrai que je n'ai pas trop insisté.
Par contre, tous les exemples donnés en MikroC fonctionnent en .hex et recompilés après modifications, je regrette seulement qu'il faille deviner les instructions au travers d'une documentation par ailleurs bien fournie.
Il est vrai que easy4, Picflash et mikroC sont de la même maison. Easy4 est un jouet très simple et très agréable avec lequel on peut réaliser tous les circuits de base.
Il est certain que tous les compilateurs fonctionnent, je vous livre ici simplement mon expérience de débutant.

Me voici donc arrivé à une phase de programmation qui occupe mes longues soirées d'hiver.


Comme références bibliographiques, deux ouvrages qui ne donnent pas la solution exacte de ce qu'on cherche mais qui indiquent beaucoup de pistes pratiques:
Moteurs pas-à-pas et pc de P. Oguic
Programmation en C des Pic de C. Tavernier.



#7083 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 21 octobre 2006 - 09:21 dans News dans le domaine de la robotique

bonsoir,
Epilogue.
J'étais pratiquement décidé pour AVR quand j'ai rencontré les profs du Génie Electrique de l'IUT qui s'intéressent à mon problème pour en faire un projet étudiant, comme ils sont Pic, ce sera Pic avec un Pic pour les calculs et un Pic par axe.
Pour la commande des pap, j'étais décidé dans un premier temps pour une solution L297 + 2 x L6203 or selectronic commercialise une telle carte pour le prix des composants, mes essais commenceront donc avec.
Je pense qu'ultérieurement j'ajouterais dans le programme une affectations des pulsations pour supprimer le L297 et n'utiliser que 2 MC33886.
Je vous tiendrais au courant de l'avancement de ce projet, de ce qui marche et ne marche pas.



#6861 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 12 octobre 2006 - 09:42 dans News dans le domaine de la robotique

Bonsoir et merci pour ces renseignements.



#6833 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 11 octobre 2006 - 10:19 dans News dans le domaine de la robotique

Bonsoir,

Je ne sais pas si c'est une bonne analyse, je viens de reprendre toute la doc AVR, elle doit être plus précise pour les inités mais moins claire pour les non initiés.
Comme il existe sur ce site des spécialistes donnant de très bons conseils, je me permet d'abuser. Merci.
Pour commencer sur des bases saines, j'aurais bien voulu avoir un kit faisant à la fois la programmation et une utilisation simple tel que l'affichage sur un afficheur de valeurs récupérées sur pc et traitées par le programme enregisté. Le STkit200 pour un ATmega88 répond-il à cette question ? en général sur les autres kit, il existe une prise pour la programmation et une autre pour une utilisation.
L'offre logicielle liée à ce kit est-elle suffisante ? sachant que je n'ai rien d'autre.
Il existe aussi l'easy3 mais je n'ai pas compris son offre logicielle, j'ai cru comprendre qu'il fallait en plus un langage de programmation.
Enfin, pour piloter en même temps plusieurs axes de façon continue, il me faudra un uC par axe et un pour le calcul, est ce que ces bêtes la s'interfacent facilement pour se passer les infos: celui dédié au calcul récupérant les données du pc et les traitant pour les envoyer aux autres.



#6688 Isolation galvanique d'un microcontrôleur

Posté par H.Cou29 sur 05 octobre 2006 - 10:05 dans Electronique

Bonsoir,

Voilà ce qui est dit la notice d'un uC:

Lorsque vous utiliser les ports en entrées, n'utilisez jamais de grands fils pour y raccorder des boutons-poussoirs et autres capteurs sans avoir recours à un circuit de mise en forme et de protection. Si vous n'utilisez pas de protections de ce type, limitez la longueur des fils à 3 - 4 cm.
Pour les poussoirs ils indique de prendre des 18T1. Pour les entrées analogiques, il est dit que l'on peut utiliser un optocoupleur mais sans donner de référence, je pensais que pour avoir une réponse linéaire, il en fallait un particulier.



#6617 Isolation galvanique d'un microcontrôleur

Posté par H.Cou29 sur 03 octobre 2006 - 11:30 dans Electronique

Bonjour,

Les mots ne sont peut-être pas les bons: isolation galvanique ou découplage, photocoupleur ou optocoupleur: j'aurais dû appelé ça principes de précaution.

J'alimente le module Uc sous 5V régulé filtré, je dispose d'une autre alim 5V pour les accessoires qui peuvent être situés à 2m du module et ramasser au passage des parasites, il s'agit uniquement de la circuiterie externe au boitier contenant Uc et alim moteurs.

D'abord en numérique.
En entrée d'Uc j'ai des boutons poussoirs, des interrupteurs manuels et de fin de course.
En sortie d'Uc essentiellement des led, peut-être des relais miniatures.
En entrée analogique, j'utilise les convertisseurs A/N internes à l'Uc , la tension provient d'un potentiomètre alimenté 0V-5V.
Quelles précautions prendre avec quel matériels conseillés.



#6602 Isolation galvanique d'un microcontrôleur

Posté par H.Cou29 sur 02 octobre 2006 - 02:52 dans Electronique

Bonjour,

Pour interfacer un micro-contrôleur, j'ai de la doc me disant ce qu'il faut et qu'il suffit, dans les boutiques, on trouve des tas de modèles, difficile de faire le bon choix.

1- En entrée numérique, il faut un photocoupleur qui n'a pratiquement rien à débiter.
2- En sortie numérique, il faut aussi un photocoupleur devant débiter de quoi alimenter un relais.
Pouvez-vous m'indiquer des références de produits qui vous donnent satisfaction ?

3- En entrée analogique ???: simple zéner + 1N4148?
Existe-t-il l'équivalent d'un ampli op de gain 1 ne fonctionnant qu'avec du 0 et +5V ?
Autres systèmes simples, photocoupleur linéaire?

Merci d'avance.



#6601 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 02 octobre 2006 - 02:40 dans News dans le domaine de la robotique

Bonjour,

Le sujet du post était PicBasic ou Rovin, je pense que cela ne sera ni l'un ni l'autre.
Certainement que l'on peut faire beaucoup de choses en assembleur cad avec un logiciel adapté (qu'il faut avoir et bien maitriser), la programmation en basic étant certes plus simple mais moins riche en possibilités.
Certains pic pourraient satisfaire mon problème mais au prix d'une programmation qui aujourd'hui me dépasse un peu.
Du fait de leur caractère multi-tâches, les Rovin gèrent mal (tout au moins de façon simple) les "delay".
L'auteur d'une carte Universelle à PicBasic m'a vivement conseillé l'utilisation d'un Cubloc qui effectivement me permettrait de programmer facilement deux axes. Au travers de la doc, c'est le seul Uc dans lequel j'ai l'impression de m'y retrouver pour commencer simplement, ceci sans fermer la porte à un développement plus fin ultérieurement.



#6289 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 18 septembre 2006 - 01:43 dans News dans le domaine de la robotique

Réponses et réflexions, très en vrac.

-1 Avec des aéronefs peu rapides, avions de club, hélico, parapente, le pilotage "aux fesses" c'est à dire par les sensations ressenties au niveau du corps, est très important. Quand tu te sens partir en avant c'est ton bras qui tire sur le manche sans que ta tête ne semble préocupée par cette tâche. En simulation, c'est presque plus difficile qu'en réel car tout ce fait uniquement à partir de ce que tu vois à l'écran, on a là un bel exemple de multi-tâche. C'est une partie de ces sensations que je voudrais récupérer .

-2 Dans les drivers industriels de moteurs pas à pas, en dehors de la gestion du mouvement existent en général 2 fonctions supplémentaires, la réduction de courant à l'arrêt afin de réduire l'échauffement et le boost au démarrage. Ces fonctions doivent être activées ou non une fois pour toute dans le programme. Je dois avoir prévu assez de puissance pour ne pas utiliser le boost, mais j'ai noté de l'intérêt pour la fonction réduction d'ailleurs très peu contraignante.

-3 Dans le logiciel de simulation FlyII, mon collègue m'a fait une dll qui me récupère l'angle de tangage pitch_vrai (200 pour 20°), ce toutes les 0.1s.
A partir de cet angle et de la mémorisation de la position (simulée) de la mécanique neff1, j'ai fait en m'imposant des limites pour la vitesse du moteur ainsi que pour son gradient, un programme ( if..if..if) qui calcule la vitesse du moteur et le nombre de pas à effectuer pendant le cycle. Ce n'est pas un véritable
asservissement, je ne fais que courrir après une valeur. Je ne pense pas qu'en 0.1s on puisse faire mieux, si ça monte pendant 2 cycles, ce n'est pas évident que ça monte encore au troisième. Partant de la position 0, je peux voir de proche en proche le suivi du mouvement. Naturellement je ne suivrais pas un looping, (je ne fais pas ça pour la foire du trône).
Quand la dll est activée, la fonction debug me crée un fichier texte dont je donne un extrait:

----------------------------------------------------------
pitch_vrai pitch_limite neff1 (time_counter) [f2th f2 neff2]
080.4678 0080 00000080 (000.0940) [-00040 -00020 000081]
082.1016 0082 00000081 (000.0973) [000040 000020 000081]
084.0176 0084 00000081 (000.1171) [000040 000060 000085]
085.3004 0085 00000085 (000.1009) [-00060 -00040 000086]
087.2813 0087 00000086 (000.1202) [000060 000040 000086]
088.7275 0088 00000086 (000.1030) [000000 000020 000089]
091.0509 0091 00000089 (000.1237) [000020 000040 000092]
092.6577 0092 00000092 (000.1077) [-00040 -00020 000093]
095.0603 0095 00000093 (000.1261) [000060 000040 000094]
096.7749 0096 00000094 (000.1124) [000000 000020 000097]
098.4307 0098 00000097 (000.0955) [000000 000020 000099]
100.9362 0100 00000099 (000.1155) [000000 000020 000101]
102.5916 0102 00000101 (000.0979) [000000 000020 000103]
105.1055 0105 00000103 (000.1177) [000020 000040 000106]
106.7537 0106 00000106 (000.0997) [-00040 -00020 000107]
109.1820 0109 00000107 (000.1198) [000060 000040 000108]
110.6183 0110 00000108 (000.1022) [000000 000020 000111]
112.4527 0112 00000111 (000.1208) [000000 000020 000113]
113.5322 0113 00000113 (000.1035) [-00020 000000 000114]

Il faut comparer la première colonne pitch_vrai (ex: 080.4678) qui est la valeur à suivre, neff1 (3ème colonne: 0000080) qui est la position du système et neff2 ( dernière valeur à droite ex:000081) celle qui est prévue pour la fin du cycle. ( neff2 sera neff1 pour le cycle suivant).

-4 Toutes les 0.1s récupérer les données, les traiter, sortir les impulsions en une seule tâche, ça veut dire que 10ms seront consacrées au traitement et que pendant ce temps le moteur doit être mis en roue libre, d'où la nécéssité d'un retour d'information. Je pense que c'est acceptable avec une liaison élastique qui absorbe les à-coups.

-5 Mon réflexe primaire de mécano m'avais conduit à décomposer les problèmes et c'est pourquoi je souhaitais une commande indépendante du pc pour les essais, (d'autant que pour l'instant, pc et mécanique se trouvent dans des endroits différents). Après réflexion, on peut adjoindre à l'Uc potars et boutons poussoir ainsi qu'un programme simple pour une commande manuelle du moteur, je retire donc une carte !



#6237 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 16 septembre 2006 - 10:48 dans News dans le domaine de la robotique

Bonjour,

Concernant le but du composant annexe:
La valeur du courant alimentant les phases du moteur est réglé par la valeur d'une résistance quelque part dans le circuit.
Le composant annexe permet de mettre une autre résistance en parallèle avec la première si aucun ordre de marche n'est donné au moteur, c'est une opération indépendante du logiciel, pourquoi s'en priver.

Début de cahier des charges !
D'abord une précision sur ce que je veux faire:
J'envisage dès maintenant 2 axes identiques, en laissant une possibilité pour un troisième si ça ne complique pas. On ne fera cependant qu'une seule carte d'alimentation pour 1 moteur pour faire les essais.

Organisation matérielle.

Je verrais (conditionnel) une platine contenant les alimentations contrôle (5V) et puissance, sur laquelle viendrait s'enficher les cartes:
-- Uc et dialogue avec le port série ( max 232)
-- Alim moteur 1
-- alim moteur 2
-- place pour alim moteur 3
-- place pour carte de gestion autonome

La carte de gestion autonome, comprendrait:
une sélection de l'emplacement de la carte du moteur à commander,
un commutateur de marche AV et AR,
un potar de réglage de vitesse,
un poussoir de marche (en vitesse lente, avance de pas à pas).
Cette carte génére des impulsions pouvant faire fonctionner les moteurs via leurs alims mais indépendamment de l'Uc et comme j'opte pour une mesure de position par potentiomètre, un simple voltmètre me permet de repérer la position et suffit pour les essais de la mécanique.


Sans trop entrer dans le détail, le rôle de l'Uc serait:
le dialogue avec le pc,
la gestion des asservissements,
La sortie des trains d'impulsions.

En fonctionnement normal le dialogue avec le pc se résume à la receptions des infos, mais pour les essais, je souhaiterais renvoyer sur le pc l'info de la position de la mécanique pour qu'en mode debug, je puisse vérifier la qualité de l'asservissement. Actuellement dans le pc, j'ai fait une simu d'un asservissement et j'enregistre dans un fichier texte les positions données par le logiciel et celles sensées être obtenues après asservissement.

Je ne pense pas que le retour de position soit utile, mais il vaut mieux la prévoir en conv. A/D sur l'Uc.

Tous les x temps (x varie de 0.10s à 0.15s), le pc envoie une info (3 fois 2 octets) qui doit générer une interruption dans le programme d'asservissement, ces valeurs sont reprises par l'Uc qui calcule alors les éléments du fonctionnement moteur pour la durée de 0.15s qui suit. Je serais en retard d'au moins 0.15s.

Pour fabriquer des impulsions pour une sortie, je vois à peu près comment faire mais, pour deux sorties en même temps, avec des fréquences différentes, je cale.

Voilà où j'en suis en cette fin de jour.



#6187 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 14 septembre 2006 - 09:31 dans News dans le domaine de la robotique

Bonsoir,

Encore bonne pioche.

Le pas à pas de Selectronic est moitié moins cher que le Sanyo, il est un peu moins puissant, mais comme je suis surdimentionné, même si sa courbe est moins bonne, il devrait faire l'affaire.

Sur le site de DigChip à mc33887 j'ai obtenu mc33888 qui semblait aussi adapté au problème.
Sur le site de Freescale, j'ai bien récupéré la doc du mc 33887. C'est celui la que tu conseilles. Peut-on lui adjoindre un circuit genre 74 LS 123 ou autre afin de réduire le courant quand il ne reçoit pas d'impulsions car je ne sais pas si non alimenté le couple de maintien est suffisant.
Autre question, si j'opte pour une boucle fermée, le plus simple sur le plan mécanique est un potar sur l'axe, mais ça impose une entrée analogique suivie d'une conversion. Il serait plus logique de rester en digital, on peut mettre une roue dentée mais peut-on distinguer le sens de rotation afin de compter et décompter ?



#6170 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 13 septembre 2006 - 10:01 dans News dans le domaine de la robotique

Bonsoir,
Merci pour la doc, je l'ai récupérée.
J'ai trouvé des moteurs qui me conviendraient du point de vue puissance-couple, et des alim toutes faites hors de prix, ça donne quand même des idées de ce qui faut faire au point de vue commande.
Evidemment, ce que l'on choisit sur catalogue n'est pas dispo. J'avais trouvé un 2A/phase pour lequel existent de nombreux schémas de carte puissance, il n'est dispo qu'en 4A/phase, c'est plus puissant mais...
J'avais envisagé un montage avec association L297 +L298 décrit par P. Oguic, il est pour 2A max toutefois, l'auteur signale que l'on peut mettre en parallèle 2 circuits L298 à raison de deux sorties sur chacun d'eux pour augmenter la puissance. Sur le papier ça devrait fonctionner mais ça n'a pas l'air d'avoir été utilisé, si quelqu'un pouvait confirmer, car il faut bien doubler le courant de sortie.



#6147 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 12 septembre 2006 - 09:47 dans News dans le domaine de la robotique

Bonsoir,

Je te remercie d'avance pour une aide éventuelle.
Au fur et à mesure que je rentre dans la doc, et que j'affine la mécanique le concept évolue et je ne suis pas encore mûr pour un cahier des charges suffisamment précis pour être pris en compte, je pense que d'ici une quinzaine j'aurais un axe de parfaitement défini. Wait and see.



#6082 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 10 septembre 2006 - 06:48 dans News dans le domaine de la robotique

Bonsoir,

D'abord merci des renseignements que vous m'avez communiqués, J'y trouve des éléments que je n'avais pas.
Voilà le berceau devant recevoir la cellule de la photo précédente. (il y a encore des liaisons à refaire).
Pour les essais et réglages, le pilote est remplacé par un bidon de 25Kg mais grâce au verin, ça bouge avec le petit doigt.

Image IPB

Dans un premier temps j'ai pensé à une suspension par sandows mais il en fallait au moins 10m en 3 brins avec des poulies de rappel, j'imagine Gaston assis sur le siège, en train d'expliquer à mlle Jeanne le fonctionnement ... je vous laisse terminer.

Pour ce qui concerne la commande:
1- Une dll dans le logiciel FlyII récupère les angles de tangage, de roulis et de lacet à une fréquence variable, toutes les 0.09s à 0.13s, parce que le taux d'images dépends de la complexité des scènes. C'est un collègue de jeu qui me fait cela en C, (je ne sais pas faire)
J'ai fait essayer un programme de simulation d'asservissement relié par un socket à une dll mais ça consomme trop de ressources.
Je ne peux pas faire faire le prog d'asservissement dans la dll car il faut que j'en reste maître, la dll ne peux que m'envoyer ces valeurs par le port série.

2- Il me faut un microcalculateur capable de gérer les asservissements:
récupération des angles,
récupération du passage à la position 0 de la mécanique,
gestion du programme,
sortie continue des impulsions de commande des pap,
gestion des fins de course et de la sécurité,
ceci de préférence de façon séparée pour chaque axe pour ne pas tout refaire après le premier axe.

3- La carte puissance d'alim des pap ne devrait pas présenter de difficultés, ça existe.



#6027 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 08 septembre 2006 - 06:36 dans News dans le domaine de la robotique

Bonsoir,

Un aperçu de la partie qui devra bouger:

Image IPB

(le casque est là pour la frime)

Il faudra attendre quelques jours pour le berceau, il est actuellement en pièces détachées.



#5998 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 07 septembre 2006 - 05:53 dans News dans le domaine de la robotique

Merci pour ces conseils qui correspondent bien à ce que je pense, pour l'acquisition d'un uC il est urgent d'attendre.



#5981 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 06 septembre 2006 - 09:28 dans News dans le domaine de la robotique

Bonsoir,

Tu as bien compris le problème et effectivement résumé ainsi, ça peu paraître simple, j'épluche les notices des Pic et j'ai le bouquin de P. Oguic sur les pas à pas. Y a-t-il d'autres références de base ?
Ce que je ne vois pas clairement c'est la gestion continue de la variation de vitesse, quelle est l'astuce pour programmer une rampe ? si quelqu'un sait merci d'avance.



#5947 PRESENTEZ VOUS :)

Posté par H.Cou29 sur 05 septembre 2006 - 11:50 dans Et si vous vous présentiez?

Henri Coudeville
68 balais, retraité
ex prof de mécanique en IUT
Le vol réel étant un peu trop cher, je fais de la simulation sur FlyII (plus de conceptions 3D et 2D que de vols).
Ma dernière folie, une cellule qui laisserait l'horizon horizontal sur l'écran (enfin presque). Ce n'est peut être pas de la robotique mais ça y ressemble un peu.



#5946 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 05 septembre 2006 - 11:36 dans News dans le domaine de la robotique

Bonjour,

Je construis une cellule de simulation de vol d'hélicoptère et je veux asservir les mouvements de mon siège à celui de l'hélico du simulateur.
Dans le simulateur qui est FlyII, j'ai une dll écrite en C qui me récupère l'angle de tangage (pour commencer) à raison d'une mesure toutes les 0.1s et qui pourra me l'envoyer par un port série.
Mon idée est d'utiliser les vérins électriques de pilotes automatiques de bateaux actionnés par des moteurs pas à pas. Je termine la mecanique pour mesurer exactement les inerties qui nécéssiteront certainement des contrôles par rampes.
Le module Convin de chez Comfile me séduisait par le fait qu'il était multitâche, les 3 axes pouvaient être fait un par un et avec d'autres choses par la suite. (et avec une notice en français).
Avant d'acheter ce module, je cherche à savoir s'il est fiable et non buggé, c'est déjà assez compliqué quand ça fonctionne.
Maintenant, il existe certainement des modules plus simples et plus adaptés mais je n'ai pas assez d'expérience pour faire d'emblée le bon choix, vos expériences et conseils sont les bienvenus.



#5928 Pic ou Convin à base de ARM

Posté par H.Cou29 sur 04 septembre 2006 - 10:05 dans News dans le domaine de la robotique

Bonsoir,
J'ai trouvé beaucoup d'exemples à base de Pic et rien à base de Convin, peut être ai-je mal cherché ? tous les deux sont vendus par Lextronic.
Je suis preneur de toute expérience avec ce module.