Aller au contenu


Contenu de eihis

Il y a 63 élément(s) pour eihis (recherche limitée depuis 03-avril 13)



#52114 service de programmation eprom / mcus / Gals etc

Posté par eihis sur 12 décembre 2012 - 10:11 dans Reventes, matériel d'occasion, récup

salut,

oui, je comprends ton point de vue : pour tout ce qui est microcontroleurs, un kit d'upload suffit ( pickit...etc ) , mais ca se complique pour les GALs , EPLDs, FPGAs ,d'ou l'idée du service.

La copie de proms de cartouches de jeu de consoles plus ou moins agées est aussi ciblée,
ainsi que la programmation des proms pour modification des injections pour le tuning auto ( peu de gens sont équipés du materiel nécéssaire ).

mais bon, ok, je prends note de tout ça.

concernant les modules (arduino) ,
pouvez vous me donner une rérérence exacte ,
puis le prix le plus bas trouvé a l'heure actuelle pour ce module ? ( citer le site vendeur )

merci @+



#52093 service de programmation eprom / mcus / Gals etc

Posté par eihis sur 11 décembre 2012 - 02:09 dans Reventes, matériel d'occasion, récup

Bonjour,

je me suis peut etre mal exprimé. le service fourni serait uniquement celui du transfert : le client fournit le fichier source + la ref. du composant a programmer. Il reçoit ensuite chez lui le composant, programmé avec le source qu'il a fournit ( fichier .HEX , .BIN , .JED etc...)



#52085 service de programmation eprom / mcus / Gals etc

Posté par eihis sur 11 décembre 2012 - 10:45 dans Reventes, matériel d'occasion, récup

Bonjour,

Dans le cadre de l'extension des activités de ma société, je m'interroge sur la pertinence de proposer un service de programmation de composants type eprom,eeprom, pals, gals , MCUs (PIC , ATMEL etc ), avec envoi des fichiers numériques source ( Jedec , .HEX , etc ) et fourniture du composant a programmer.
La tarification serait basée sur le prix réel du composant ( source : farnell / RS etc ) + un tarif fixe pour la programmation (selon taille du fichier ou type de composant ) + cout expédition.

pensez vous que ce genre de service peut etre utile sur le web.
existe t-il déja ? si oui, ou ça ? , qui ? , quels tarifs, quels délais ?

Ensuite, je souhaite distribuer des composants et modules de qualité, importés d'asie.
Pourriez vous me donner une liste de composants/ modules que vous employez regulierement, et dont les prix sont , a votre avis, trop élevés ? ( exemple : afficheurs 128x64 , arduino... etc)

merci d'avance pour vos réponses!

stef



#19396 Une main robotique pour handicapés

Posté par eihis sur 22 février 2011 - 06:30 dans Assistance à la personne

bonjour,

je rentre un peu tard sur le sujet, mais je commence a m'y interresser depuis quelque temps.
en ce qui concerne le traitement des signaux electriques captés sur le corps (signaux nerveux), je me demande si un reseau de neurone ne serait pas le plus adapté : l'individu peut directement faire lui meme la phase d'apprentissage au reseau (modification du poids des liaisons...)

j'ai malgré tout des doutes par rapport a l'autonomie de systemes comme ceux la : si une main 'bionique' fonctionne 2h au maximum, c'est plutot génant.

@ bientot pour des news :
j'attaque le sujet avec un montage expérimental de captage des pulsations electriques et je vous tiendrais au courant de l'évolution au fur et a mesure tu temps que j'aurais de dispo.



#19219 Transistor ou Ampli op ?

Posté par eihis sur 22 janvier 2011 - 12:04 dans Electronique

coucou !

TRANSISTOR = nécéssité de polarisation dans la zone 'linaire' + gain fixe , ce qui entraine que pour augmenter le gain , il faut ajouter des etages supplémentaires ( ce qui ajoute a chaque etage de plus du bruit superposé sur le signal 'utile'. il faut calculer les courants de repos et tenir compte donc du gain (hfe) . un mauvais montage grille facilement le transistor ( courant trop important dans le collecteur, par exemple)

AOP = impedance d'entrée théorique infinie, gain théorique infini ( on le fixe par un jeu de résistances , et les formules pour le determiner sont simplifiées car ne prennant pas en compte les courants dans le circuit. de plus la plupart sont protégés en sortie conte les C-Circuits ce qui les rend très robustes a l'utilisation 'non experte'.

néanmoins, dans la pratique, pour choisir un aop il faut regarder de près : sa tension d'alim , et son slew-rate (pente max du signal) pour savoir s'il pourra bosser dans la bande de fréquence souhaitée.

@+



#19098 programmer en c?

Posté par eihis sur 09 janvier 2011 - 04:30 dans Programmation

hello

c, c++, pascal, cobol, fortran, basic .. tout est question de compilateur , qui traduira le code en language machine.
Pourtant, certains micros sont plus 'orientés C' que d'autres ( ils comprennent dans leur jeu d'instruction machine des commandes très proches de la syntaxe du 'c' ce qui rend la compilation très efficace ( boucles 'while' par exemple.))

tu as le choix dans le language car le compilateur est la couche 'd'abstraction' avec le hard.

@+



#18917 HELP première programmation

Posté par eihis sur 14 décembre 2010 - 07:41 dans Programmation

salut !

Tu cherches a faire clignoter un led sur le port A , bit 0 :P
..ca doit marcher sur le papier,et vu le code ( meme s'il est sacrement étrange et peu optimisé ).

Les warning sont la pour te signaler que les fonctions non utilisées provenant du fichier 'include' ne sont pas compilées :
Le but est de gagner de la place mémoire . Rien d'anormal .

niveau code, TRISx sert a determiner le 'sens' d'un port (entrée ou sortie) :
il n'est pas nécéssaire de le redéclarer a chaque fois que tu accede au port ( ca n'a pas lieu d'etre sauf si tu as modifié depuis le dernier accès le 'sens' du port [lecture->ecriture et vice- versa])
A part ça, tu devrais prendre l'habitude d'écrire les variables/mots cles en majuscule pour différencier tes variables propres des variables 'reservées'.
ecrire TRISA au lieu de trisa , par exemple, ou 'PORTA' plutot que porta. c'est con, mais ca aide bcp a clarifier le programme quand on le relit :D

A part ça,attention aux bits de config, au moment de transferer le prog. (ne pas mettre par exemple le WatchDog en route si ton programme ne le gère pas (ce qui est ton cas il me semble, avec ce bout de code) ^^ ..
EN ICSP, ca tourne surement, moyennant une config correcte sur les fameux bits 'de config'.

...avec un bootloader, ces bits ne sont surement pas utilisés (mais j'en suis pas sur.. a toi de fouiner dans la config du logiciel )
egalement, voit dans le compilateur si tu peux (ou dois) cocher l'option 'code relocatable' (c'est a mon avis nécéssaire pour envoyer un programme a l'aide d'un bootloader)

@+!



#18882 HELP première programmation

Posté par eihis sur 11 décembre 2010 - 07:03 dans Programmation

Merci beaucoup pour ton aide ! Je commence à y voir plus clair.
Par contre mon programmateur n'utilise pas la patte PGM mais le bootloader semble quand même installé.

J'ai réalisé cela, c'est avec ça et les pattes Tx Rx que je peux installer mon programme ? Avec quel logiciel ? J'ai aussi besoin du programme sous forme de fichier HEX ?

Sinon, comment faire sans le bootloader ?
Merci


salut !
Le bootloader, c'est un mini programme qui reste en permanence dans le PIC.
Son role est de charger un programme principal en mémoire, et de le 'lancer' : il utilise a ma connaissance toujours les broches rx/tx série du PIC.
Le bootloader occupe très peu de mémoire dans le pic,et si tu choisis d'en utiliser un, tu dois aussi en connaitre le mode de fonctionnement afin
d'initier le téléchargement d'un nouveau programme, ainsi que l'emplacement mémoire ou le bootloader va charger ce programme.

si ton bootloader utilise la liaison série du pic (ce qui doit etre le cas..),alors c'est par cette liaison que tu dois lui envoyer
les données de ton programme (le bootloader va se charger de les ecrire dans la mémoire du pic au fur et a mesure : il jour le role
d'intermediaire, qui t'évite de 'flasher' ton pic entièrement.

Le bootloader a des avantages (rapidité/simplicité) mais aussi des inconvénients : il faut utiliser un logiciel dédié pour envoyer le programme.
Pour que le bootloader entre en mode 'programmation' et attende l'envoi de ton programme par la liaison série, il y'a plusieurs méthodes
possibles comme par exemple un strap a mettre ou enlever sur ta carte , ce qui le met en état 'attente de données a charger en mémoire'.


L'autre type de programmateur utilise les broches PGxxx , et se branche sur ton pc via le port LPT ou série ou encore un port USB ,
et sur ta carte par un connecteur au broches 'normalisées' par Microchip.
Ce connecteur de programmation comporte 6 broches :

br1- VPP ----> MCLR/VPP du PIC
br2- VCC ----> vers le +5 de ta carte
br3- GND ----> GND de ta carte
br4- DATA ----> PGD du PIC
br5- CLOCK ---> PGC du PIC
br6- LVP ----> PGM du PIC

(attention, il en existe des variantes...).

Si tu programmes ton pic avec ce genre de programmateur, il te suffit d'un logiciel freeware (il en existe un bonne quantité) ,
qui demandera un fichier .HEX comme source a charger dans le pic.
J'utilise pour ma part PP18 , version 2.02 qui est sous license libre GPL, en ayant correctement configuré les signaux nécéssaire ( ce réglage dépend du montage utilisé).
Il detecte automatiquement la présence de la carte de programmation sur le port parallèle,
et la fameuse carte comporte en tout et pour tout 4 transistors + 8 résistances.

@+ !



#18848 HELP première programmation

Posté par eihis sur 10 décembre 2010 - 11:23 dans Programmation

OK, je vais sûrement faire ça...je ne dois pas trop traîner...mais j'ai pas beaucoup de sous.
Qu'est-ce que vous pensez de ça, ça ou ce qu'on trouve ?
Ce sont vraiment des programmateurs ? Il n'y a rien besoin d'autre ? Parceque ça m'a l'air très peu cher par rapport à ce qu'on trouve sur d'autres sites...


concernant ces programmateurs, ils sont tous fonctionnels.
j'utilise un prog. sur port parallele , mais pour pic 18F.
le prog. sur port parallele utilise les tensions disponibles sur le port : elles sont suffisantes pour programmer , ce qui explique le peu de composants nécéssaires ( en général, on retrouve 3 ou 4 diodes et 3 ou 4 transistors et quelques résistances) : c'est simple,et très robuste.
Par contre, il ne faut pas espérer ajouter un cable au bout : tu auras trop de parasites et tes progs vont etre mal chargés, ce qui impose de brancher ta carte supportant le pic directement 'au cul' de ton pc ( sur la fameuse carte dont on parle, branchée sur le port parallèle)

Si ces programmateurs sont simples, c'est parceque l'ICSP (In-Circuit-Serial-Programming) est simple :

si un pic a 32Ko de mémoire, il suffit pour le programmer de lui envoyer les 32Ko EXACTEMENT sur les connections prévues pour ça : une horloge (PGC) + les datas série (PGD).
2 autres broches sont utilisée : PGM (qui fait entrer le pic a l'etat 'programmation' quand elle est a l'état haut, avant de lui transferer le programme complet,
et VPP qui est la tension de programmation.
VPP peut etre : la tension normale , ou la tension 'low voltage', dans le cas des pic18 (je n'ai pas le datasheet des 16F/C et je ne sais pas si ce mode existe chez eux..)

Voila pourquoi ces montages sont si simples.
Attention quand meme, car une autre nécéssité est d'avoir une alimentation 5V extérieure pour alimenter le pic lors de la programmation (certains montages pompent les 5V sur le port parallèle, mais c'est plutot risqué)

@+



#18847 HELP première programmation

Posté par eihis sur 10 décembre 2010 - 10:53 dans Programmation

Salut,
Je pense que l'on a tout ce qu'il faut pour programmer enfin ce PIC mais puisqu'on est complètement néophyte en la matière, on espère que quelqu'un puisse nous guider :

On s'est procuré deux PIC 16F88 et un clone du PICkit2. On a trouvé le fichier HEX du Tinybootloader version 16F88 pour 8MHz interne et celui pour 20MHz (mais on ne sait pas si CCP1 est sur B3).

On a aussi téléchargé le logiciel PICkit2 et programmé (in-circuit) les bootloader sur chaque PIC sans problème.

Au niveau de la conception du vrai programme, on a je pense compris le principe (en même temps avec Flowcode…). Le simulateur nous dit que cela fonctionne (mais on n'a pas encore testé réellement).
Avec Flowcode, on arrive à traduire l'algo en C et normalement en HEX (je dis normalement parce que parfois ça ne marche pas ; on a d'ailleurs téléchargé MPLAB + HI TECH C, Code Blocks...mais on ne sait pas s'en servir.)

Le seul problème, c’est que lorsqu’on met le programme en HEX sur le PIC avec le logiciel PICkit2, le bootloader déjà installé est supprimé… Comment faire ?

Merci beaucoup !


kikou !

Le role du bootloader est justement de charger un programme en mémoire du pic sans passer par l'ICSP : souvent le bootloader utilise la liaison série pour recevoir le programme en mettre en mémoire.
Si tu programme un pic en ICSP, tu efface forcément le bootloader puisque dans ce mode de programmation, on doit envoyer exactement la quantité d'octet correspondant a la totalité de l'espace mémoire (une sorte "d'image mémoire",contenant les datas et le code programme :c'est le fichier 'HEX' généré par le compilateur.

Pour verifier que le programme est envoyé sur le pic en ICSP, il faut regarder a l'oscillo si tu as bien des signaux sur les broches d'ICSP (broches PGC,PGM,PGD) et que la broche VPP est bien mise a l'état haut (tension de programmation).
dans le cas d'un bootloader, il faut lire sa documentation , pour savoir la manip. a suivre afin de mettre le pic en mode 'load' et accueillir ton programme.

@+



#18359 Marche gyroscopique - proto "MZ"

Posté par eihis sur 20 octobre 2010 - 08:58 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Salut eihis

Trés intéressant ton travail et ton site aussi ;)

Allier la gyroscopie inertielle à la marche ça me rappelle ce brevet du CEA: FR2902870A1

ça pourra peut-être t'aider dans tes travaux!

En tous cas n'hésite pas à nous envoyer des updates.

Vive Foucault....


coucou !


J'ai un peu mis de coté ce montage , ayant démarré et déja bien avancé sur un projet de micro-ordinateur a base de PIC avec RAM exterieure et tout le toutim.
Mais j'ai lu avec interet ton lien vers le brevet. j'aimerais avoir accès au 'the walking gyro' de jameson, paru dans 'robotics age vol7.1 '.. mais je crois que c'est plutot compromis (introuvable?..)

mon probleme avec 'MZ' , c'est qu'il faut trouver un moyen de rétracter très rapidement la jambe, pour pouvoir profiter au mieux de l'effet gyroscopique induit par la chute du corps du robot du coté ou l'on vient de rétracter la jambe...la solution semble etre un systeme pneumatique ou a electro-aimants (mais j'y crois peu vu le poids..) .
A part ça, une variante a tester consiterait a monter le gyro sur une base a 3 roues orientées comme un anneau autour d'un corps circulaire.

la mise en route des moteurs de ces roues va entrainer une rotation du corps du robot sur lui meme par rapport au plan du sol : hors si un gyroscope tourne en meme temps , solidaire de ce corps, alors l'ensemble devrait se soulever d'un cote ou de l'autre, selon le sens de gyration du corps par rapport au plan du sol(en d'autres termes, on fait tourner le corps sur l'axe Z si XY est le plan du sol).De la, en alternant des rotation 'horaires' / 'inverse-horaires' succéssives, on devrait obtenir un engin qui se déplace d'une facon peu orthodoxe , en prenant appui sur le sol par un double effet de reaction(friction) + precession . Je m'y colle quand j'aurais un peu plus de temps !

Merci pour ton lien et ton commentaire ! ++



#17734 Quelques questions sur les outils

Posté par eihis sur 13 août 2010 - 04:44 dans Hack mod customisations et autres modifications

bonjour,
j'arrive un peu sur le tard, mais concernant le fer a souder, je ne suis pas du tout daccord avec ce que je viens de lire.

Il ne faut pas confondre puissance et température du fer.
un fer thermoregulé de 80W fait du super boulot et ne brule aucune piste.
l'erreur de base, c'est de prendre un fer trop puissant s'il n'a pas de régulation de la température de panne.
En fait, en prenant un fer moins puissant ( passer du 30w au 18w comme j'ai pu le lire), c'est déplacer le probleme : le fer chauffe moins, effectivement, mais des qu'il s'agit de chauffer une connection un peu epaisse ou un plan de masse, ton fer colle et tu n'arriveras plus a chauffer ta soudure (boulot de m...).

Je parle en connaissance de cause, je fais de la maintenance electronique industrielle et je bosse tous les jours avec un weller WP80 de 80w sur des cartes avec et sans CMS, en multicouche. si je brulais des cartes , y'a longtemps que j'aurai perdu mon job...

En conclusion, il vaut mieux investir 50 à 60 euros dans un fer (en station) thermorégulé de 45w à 60W plutot que dans un fer 20w non régulé a 15 ou 20 euros qui ne permet pas la souplesse de travail que fournit le premier cité... mais tout dépent de ce que tu comptes faire avec, dans quel but, de la frequence d'utilisation, bien entendu...

@+



#17732 Combat avec les transistors

Posté par eihis sur 12 août 2010 - 09:12 dans Electronique

leon a dit: "J'avoue que je n'ai pas non plus compris ce que veut dire eihis par "un collecteur reste un collecteu". Tu peux préciser, stp?"

..je pensais pas que tu releverais un truc dans ce genre.
en fait, faut pas m'en vouloir, mais parfois je me demande a quoi servent tes remarques.. tu tiens un compteur de posts ?

@+



#17723 Combat avec les transistors

Posté par eihis sur 11 août 2010 - 04:12 dans Electronique

koukou..

tu devrais relire un article sur la différence entre PNP et NPN : un collecteur reste un collecteur.. enfin bon, cherche un peu plus ! :P

si tu ne vois pas de quoi je parle, commence par prendre un NPN pour tester le mode commutation : VBE doit etre positif, VCE doit etre positif aussi.

@+



#17436 Marche gyroscopique - proto "MZ"

Posté par eihis sur 20 juillet 2010 - 08:23 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

@ Dr calvin :
Bon, voila pour toi : j'ai compressé sans aucune retouche les 2 videos dans un seul fichier ZIP.
sur windows xp, elles s'ouvrent sans probleme, en provenance directe de mon app. photo.
Donc si tu n'arrives tjs pas a les ouvrir euh... je rends mon tablier!

@bientot !

ps : pour la video '16' , il faut augmenter le contraste/luminosité sous mediaplayer sinon ce sera 'ecran noir' , l'image est très sombre.

Fichier(s) joint(s)




#17409 Marche gyroscopique - proto "MZ"

Posté par eihis sur 19 juillet 2010 - 09:07 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

coucou!

bon pour répondre a Dr calvin : y'a un mystere.. pour moi, la video s'est lue sans problemes sur media player...je ne sais pas quoi dire de plus. il faut obligatoirement l'encoder pour limiter sa taille. peut etre que le souci vient de l'encodeur utilisé...

@thot :
le gyroscope tourne toujours dans le meme sens, tout au long de l'essai.
C'est le changement d'appui (quand l'une des jambes se relève) qui crée un deséquilibre : le gyroscope, 'tombant' du coté de la jambe qui s'est relevée, il effectue pendant sa chute la rotation (precession) dont le proto se sert pour avancer, en changeant alternativemet d'appui.
question vitesse de rotation , je n'ai pas de valeur connue. j'ai utilisé 2 moteurs de récup ( moteur de tiroir de chargeur CD pour PC) qui sont peut longs, et ont un bon couple tout en etant peu gourmands .la roue du gyro elle meme vient d'un gyroscope (nature et decouverte) recyclé.

En fait, je suis en train de mettre au point une autre version de pieds, pour eliminer les 'roulettes' actuelles, et permettre une torsion par rapport au sol, de maniere a mieux transmettre a celui ci la rotation impliquée par le gyroscope (l'ajout de potar a c eniveau permettrait la mesure de la rotation par rapport au sol et donc la gestion aisée du moment ou la jambe doit redescendre au sol, afin d'eviter les 'demi tours' intempestifs ).
a part ça, et globalement, l'ensemble des liaisons gagneraient a etre plus 'souples'... et plus 'organiques' il me semble..


@bientot pour des news et merci pour vos com's !!



#17370 Marche gyroscopique - proto "MZ"

Posté par eihis sur 18 juillet 2010 - 05:28 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Bonjour !

cette fois ci, la video s'ouvre dans windaube-media-player sans problemes, mais j'ai du mal a gerer entre la taille et le taux de compression niveau encodage ...et si on rajoute des conditions d'eclairage plutot mauvaises au sol de mon garage... on obtient cette nouvelle video.
Il faut etre indulgent avec "mz", ce sont ses premiers pas. je tiens la caméra en meme temps que j'actionne les potars du boitier de commande, d'ou le coté hésitant de la démarche :P

pour bernard : la premiere version utilisait le mouvement complémentaire a celui ci : une rotation dans le plan horizontal entrainait l'alternance de va et viens perpendiculaires au sol, faisant 'ramper' l'engin.

Sur celui ci, j'ai utilisé l'effet contraire : la rotation dans un plan perpendiculaire au sol (provoquée par la levée de la jambe concernée) engendre une rotation de tout l'engin sur le plan parallèle au sol.
Je constate plusieurs choses assez hallucinantes, et en premier lieu, l'equilibre de l'engin : malgre une répartition des masses qui ne l'avantage pas du tout, le gyroscope rend le robot très stable ( il n'y a qu'a en juger au rapprochement des pieds vers l'interieur ).
De plus, le ptit engin est monté sur 4 vilains roulements a bille (en attendant un autre systeme a roulettes caoutchoutées ou boules... je ne sais pas encore) et ne s'en soucie pas des masses.
Enfin, l'ajout du pack de 5 accus nimh a renforcé l'effet de precession sans grever la vitesse des servos.
A propos d'eux, dailleurs, j'ai rajouté des ressorts , utilisés en torsion, pour augmenter leur vitesse de 'levage', dans le but d'obtenir une 'jambe' capable de se retirer très vite du sol. (mes servos bas de gamme ne sont pas des betes de concours niveau vitesse :/)
Pour finir, le changement de direction s'obtient en modulant le temps ou la jambe est relevée (ou en modifiant la hauteur de la jambe-pivot en opposition)

Enfin bon, voila la ptite video de 50Mo tout de même , format AVI , zippée.
y'a encore du boulot mais ca vaut surement le coup d'avancer sur ce projet a mon avis.

@+

Fichier joint  P16.zip   28,77 Mo   267 téléchargement(s)



#17330 Marche gyroscopique - proto "MZ"

Posté par eihis sur 17 juillet 2010 - 10:33 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

kikou !

Effeverscence dans mon garage ! .... la version bipède de MZ fonctionne.Je peaufine ma mecanique et une video suivra très bientôt.
J'ai utilié un gyro refait en 'solide' + 2 servos, 1 pour chaque patte.
L'ajout du pack d'accus nimh de 6v augmente la puissance du mouvement de precession, c'est la cerise sur le gateau !

@bientôt!



#17301 Language NXC

Posté par eihis sur 13 juillet 2010 - 11:11 dans Programmation

oui je sais, j'arrive tard...

pour le 'sign(x)', je pense qu'au niveau du language ca permet de distinguer une opération sur un nombre non signé ( unsigned char, integer, long, double etc) par rapport a un entier signé. binairement parlant, la notation est la meme , mais la diférence est de taille.
un octet (unsigned char), non signé, va de 0 à 255 alors qu'un octet signé (char) va de -127 a +128 si ma mémoire est bonne
si ce language est dérivé du C, il y'a de fortes chance que se soit la réponse a ta question.

@+



#17291 Marche gyroscopique - proto "MZ"

Posté par eihis sur 13 juillet 2010 - 05:19 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

coucou léon ! (non, je ne suis pas un leve tot, mais la, je pars au boulot :P !

Oui l'idée m'est venue lors d'une reflection sur les moyens de stabiliser un engin bipede, et, de facon plus generale, sur l'eventualité de simplifier la mecanique 3axes des articulations
En manipulant le gyro a un certain rythme oscillatoire, j'ai ressenti dans les mains ce mouvement "de marche" de facon très claire.

Pour la queue, un caoutchouc y est collé pour en augmenter l'adhérence. dans le cas du mouvement représenté sur la video, l'ideal serait une roue caoutchouc : adhérente en translation, et libre en rotation, a mon avis.
Au dela de ça, et pour eviter le contact 'frottant' avec le sol, j'en suis a me demander si l'oscillation d'une masse autout de son axe (les accus, peut etre !?) ne serait pas suffisante pour engendre le mouvement de marche. ( comme tu le dis justement : j'ai constaté lors d'essais antérieurs que l'augmentation de poids sur la queue augmentait aussi l'amplitude de la rotation necessaire).
Dans tous les cas, un robot qui utilise 2 gyros , un sur chaque ensemble avant et arrière, serait capable d'avancer , par simple oscillation sur le pivot qui joindrait ces 2 elements.

Il y'a aussi peut etre une autre piste a explorer : si la rotation sur le plan 'du sol' engendre cette precession, il est sera de meme pour la reciproque. donc, il y'a matiere a essai : faire osciller des 'pieds' de facon perpendiculaire au sol (equivalent a une rotation du gyro sur un plan perpendiculaire au sol) devrait egalement engendrer un mouvement d'avance de ceux ci, il me semble ...

affaire a suivre ! :)



#17287 Marche gyroscopique - proto "MZ"

Posté par eihis sur 12 juillet 2010 - 08:35 dans Robots à pattes et jambes, humanoïdes, bipèdes, quadrupèdes, hexapodes ...

Bonjour,
Voila une petite video (23Mo) d'un vilain proto pourtant nommé 'MZ', en pleine reptation :wub:
J'ai décidé d'explorer la voie du gyroscope comme 'moteur' de marche bipede (je sais, c'est tordu, mais ca m'est venu comme ça..)
En attendant d'etre bipede, le proto est tripode...
Pour faire vite,la precession ( reaction a la torsion de la queue arriere ) entraine la marche du proto : il prend pivot sur ses 'pieds' (balles de souris en caoutchouc) de facon alternative, tout en allégant la patte opposée dans le meme temps.
La prochaine étape consistera a augmenter l'amplitude des mouvements jusqu'au décollement complet des 'pattes' du sol pendant le mouvement de marche, ce qui va necessiter d'articuler la queue par rapport au corps.

NB :L'inversion du sens du rotation du gyroscope entraine une marche "a reculons" du proto.D'ailleurs,dans la deuxieme partie de la video, je débranche le gyroscope pour mettre en evidence le fait que sans son effet, le proto n'avance plus.

Suggestions et idées d'amélioration seront les bienvenues !
Avez vous déja entendu ou vu un moyen semblable pour déplacer un robot ?

@+

PS : la video ne s'ouvre que dans winamp pour moi ( c'est pourtant un codec microsoft mais mystère..elle fait 320x240, avi, zippée pour etre acceptée sur le site)
Fichier joint  PICT0013_f2.zip   21,51 Mo   266 téléchargement(s)



#17242 Pince Robot

Posté par eihis sur 10 juillet 2010 - 09:09 dans Bras robots, pinces, tourelles, et autres manipulateurs

Bien en fait, c'est du vécu lol... :P

J'avais mesuré en statique dans les 13kOhm sur l'entrée 'pwm' de mes servos bas de gamme, mais en dynamique, j'ai constaté l'effondrement de 5v a 3v dès que les sorties du pic etaient chargées directement par le servo. l'aspect de la pulse dans cet état n'est meme plus carré, montant de facon incurvée et 'petit a petit' de 2.5v a 3v , pendant la durée de la pulse. autant dire qu'en dynamique, la charge 'vue par le pic' est trop faible.
Mais je suis quasiment certain que d'un servo a l'autre, ca peut varier voire meme etre tolérable par le pic, selon le design de l'electronique de controle du servo (circuit R/C d'integration des pulses ?) .
Lors de ce meme constat, j'ai pu vérifier que 3 sorties du pic acceptaient de fonctionner à ce 'regime' avec mes servos , mais quand je chargeais une quatrième, plus aucune des pins du port concerné ne fonctionnaient (mise en 'sécurité' pour limiter la casse).j'ai donc simplement limité le courant et ca a résolu tous mes problemes, sans agir sur le comportement des servos.

@+ !



#17241 Piloter 8 servos par potentiometres ( pic18f452)

Posté par eihis sur 10 juillet 2010 - 08:54 dans Electronique

Comme promis, un petit ZIP avec tous les elements nécéssaires ainsi que les references utiles !
Fichier joint  zip_servodrive.zip   3,56 Mo   182 téléchargement(s)

@+



#17227 Pince Robot

Posté par eihis sur 09 juillet 2010 - 05:36 dans Bras robots, pinces, tourelles, et autres manipulateurs

bonjour,
j'arrive un peu tard, désolé.

si tu attaque directement le servo avec les pins de sortie du pic, tu pourras voir qu'avec certains servo, ca 'tire' tellement qu'a la pin du pic, a l'etat haut, tu n'as plus que 3V au lieu des 5V attendus. la solution simplissime : intercaler une resistance (10k par exemple) entre la sortie du pic et le fil 'commande pwm' du servo.
Le pic a un systeme de protection : passé un certain ampérage (100taine de milliamperes) totale débité sur un de ses ports, il bloque toutes les sorties en les limitant de facon a ne pas 'bruler'. ce qui pourrait bien etre la cause des soubressauts que tu constatais.
En achetant d'autres servo et en mettant une alim plus costaud, tu n'as, a mon avis, que 'masqué' le probleme. mais si ça marche comme ça ..... :P tant mieux.

@+



#17218 Piloter 8 servos par potentiometres ( pic18f452)

Posté par eihis sur 09 juillet 2010 - 12:46 dans Electronique

Merci ça servira sûrement ;)
Peut-être que je demande trop mais une version en français et à télécharger serait peut-être utile qu'en pense-tu ?


coucou

Bon en fait, je publie toujours en anglais non pas pour frimer puisque ca me demande un effort pour traduire, mais parce que j'ai constaté que 80% des visites sur mon blog viennent de l'etranger.
Du coup, j'ai pris l'habitude de commenter en anglais les programmes,et bon... j'ai presque 40ans et il me semble que l'anglais est appris a l'ecole depuis une paire d'années ( fin de l'argumentaire justifiant le choix :) )/

Par contre, je peux effectivement zipper le tout !
(Je vais egalement ajouter quelques photos des oscillogrammes aux points clés pour faciliter la comprehension de l'ensemle).

@bientot!