Bien l'bonjour à tous,
Pour me présenter sommairement, informaticien recyclé dans l'animation auprès d'enfants hospitalisés, j'envisage d'organiser cet été la construction d'un "totem" avec les enfants et de doter ce totem de motorisations, éclairages et éventuellement sons.
Je souhaite donc procéder à quelques essais avant de leur mettre le projet entre les mains et je rencontre quelques difficultés, en particulier avec la notion de contrôle bloquant des moteurs pas-à-pas.
Je m'explique :
Le totem sera constitué d'un axe central formé de 4 sections empilables de tuyau de pvc, chaque section serait alors pourvue d'un ou de plusieurs moteurs (certains faisant tourner un plateau à la manière d'un carousel, d'autres actionnant de petits personnages etc.) et d'un certain nombre de DELs pour illuminer tout ça.
Attendu que l'investissement électronique sort de ma poche, je vais être contraint de le limiter. Je dispose pour le moment de deux cartes arduino (une Uno et une Mega), de plusieurs drivers pour moteurs pas-à-pas (un shield microbot, un shield dfrobot et deux modules dfrobot dont je peux donner les refs exactes si besoin).
A ce jour, j'arrive à faire tourner mes steppers individuellement sans problèmes et à les commander par le port série de l'ordi. Le souci se pose lorsque j'essaie d'en gérer plusieurs sur la même carte arduino. Ben oui, je découvre que la librairie stepper est bloquante, et qu'il ne m'est pas possible en l'état de commander indépendamment 2 moteurs pas-à-pas en même temps...
Du coup je m'oriente vers un usage de l'I2C, j'ai vu que certains modules de contrôle de moteurs intégraient ce protocole mais j'aurais aimé (pour limiter les coûts) intercaler un module I2C entre ma carte et les driver que je possède déjà, module qui devrait donc convertir des commandes "série" en alimentations pwm et logique...
Alors à votre avis, est-ce possible ?
Si oui, est-ce que ça existe tout fait ou va-t-il me falloir faire un montage ? (Ce que je pourrais laisser faire aux enfants, mais seulement après en avoir fait un moi-même pour m'assurer de la faisabilité de la chose.)
Voilà, désolé pour le pavé, et merci d'avance pour votre aide.
stig_mat:
...
Attendu que l'investissement électronique sort de ma poche, je vais être contraint de le limiter. Je dispose pour le moment de deux cartes arduino (une Uno et une Mega), de plusieurs drivers pour moteurs pas-à-pas (un shield microbot, un shield dfrobot et deux modules dfrobot dont je peux donner les refs exactes si besoin).
A ce jour, j'arrive à faire tourner mes steppers individuellement sans problèmes et à les commander par le port série de l'ordi. Le souci se pose lorsque j'essaie d'en gérer plusieurs sur la même carte arduino. Ben oui, je découvre que la librairie stepper est bloquante, et qu'il ne m'est pas possible en l'état de commander indépendamment 2 moteurs pas-à-pas en même temps...
Du coup je m'oriente vers un usage de l'I2C, j'ai vu que certains modules de contrôle de moteurs intégraient ce protocole mais j'aurais aimé (pour limiter les coûts) intercaler un module I2C entre ma carte et les driver que je possède déjà, module qui devrait donc convertir des commandes "série" en alimentations pwm et logique...
Alors à votre avis, est-ce possible ?
Si oui, est-ce que ça existe tout fait ou va-t-il me falloir faire un montage ? (Ce que je pourrais laisser faire aux enfants, mais seulement après en avoir fait un moi-même pour m'assurer de la faisabilité de la chose.)
Bonjour
projet sympa
tu dispose déja d'une base qui semble assez stabilisée puisque tu a déjà validé la liaison serie pour activer correctement un moteur, mais ça coince ensuite
je suppose que c'est du genre trame serie = activer le moteur 1 de x pas en avant ou en arriere et autres ?
pourquoi t'em...barquer sur de la gestion inséree de protocole differents (I2C ou autre) ?
pourquoi plutôt ne pas partir sur un "arduino" minimal standalone par moteur ? les "arduino" etant tous reliés au RX (recevant tous les memes infos series) et chacun s'occupant de gerer ensuite "son petit" 8)
un 328P préchargé avec un bootloader ça ne coute pas tres cher , un 328P vierge encore moins et tu dispose de quoi charger les bootloader
l'horloge QZ+C non plus ,et je pense que l'on peut meme si vraiment l'on veut faire utiliser une horloge commune distribuée ( I.e oscillateur dil 16 MHZ)
Il y a la solution de passer par des Attiny, encore moins chers. Mais je suis étonnée par ta librairie "bloquante", ce genre de tâche peut s'effectuer très facilement sans l'être. Au pire j'ai un code tout prêt si tu veux.
B@tto:
Il y a la solution de passer par des Attiny, encore moins chers.
tiens sur ce point c'est une question que je me suis déjà posée et c'est là HS , c'est facile/(lire pas trop compliqué 8)) de deriver du code "arduino" vers de l'Attiny (en etant evidemment conscient des limitations hard)
Nan c'est vraiment pas compliqué : il n'y que des problèmes de librairie vu qu'il manque surtout un vrai système de bus (pas de vrai SPI, i2c ...). Mais ce genre de lacune se complète assez facilement et il y a beaucoup de tuto sur le net. En tout cas perso je suis toujours arrivé à faire ce que je voulais !
B@tto:
Nan c'est vraiment pas compliqué : il n'y que des problèmes de librairie vu qu'il manque surtout un vrai système de bus (pas de vrai SPI, i2c ...). Mais ce genre de lacune se complète assez facilement et il y a beaucoup de tuto sur le net. En tout cas perso je suis toujours arrivé à faire ce que je voulais !
Merci à tous pour vos réponses, elles m'ont d'ailleurs aiguillé sur l'usage d'une autre librairie que Stepper.h, j'suis passé à AccelStepper.h et c'est nettement plus pratique !
@ B@tto : c'est l'usage des 'delay()' dans Stepper.h que je décrivait comme 'bloquant', mais le fait est qu'effectivement cette librairie me semble finalement assez primitive. Si tu en as une autre sous l'coude, j'suis preneur.
Cela dit, l'usage du port série pour communiquer avec l'ordi à toujours une incidence sur la rotation des moteurs (une légère 'coupure' est perceptible dans les plages hautes de vitesse de rotation). Du coup je me penche sur le standalone arduino-module moteur suggéré par Artouste. Même si je suppose que la synchro entre module arduino impactera forcément aussi les rotations (à moi de trouver un protocole minimaliste).
Merci donc pour vos conseils (sauf que maintenant que j'me suis lancé dans des lecture sur le Attiny, j'ai du mal à ne pas me disperser ! ).
Du coup je me penche sur le standalone arduino-module moteur suggéré par Artouste. Même si je suppose que la synchro entre module arduino impactera forcément aussi les rotations (à moi de trouver un protocole minimaliste).
J'ai adapté une partie de ce code à un ATTiny84 pour me passer d'un circuit (le hex inverter).
J'ai viré l'interface UART et géré une entrée pour la direction et une autre pour le pas (comme certains circuits de commande de moteur pas à pas). C'est minimaliste comme protocole
sur de la gestion inséree de protocole differents (I2C ou autre) ?
).