Sandro

L'idéal serait un shield avec des borniers, mais ce n'est pas dans notre budget.
Je pense que nous allons utiliser les connecteurs JWT pour relier les drivers à la carte Mega.

après 6 controleurs moteurs à 15€, une arduino mega, les 6 moteurs, la mécanque du bras, ... tu en es a 13€ près?

Mais les connecteurs JWT font aussi l'affaire (nb : il faut ajouter le prix d'une pince à sertir, sauf si vous en avez déjà une).

Les câbles des moteurs pas-à-pas sont trop courts et nous souhaitons les prolonger. Est-ce qu'il existe des connecteurs 4 fils "verrouillables" ?

Si le seul but est de les ralonger, alors je suggère simplement d'y souder un bout de fil au milieu, et de couvrir les soudures de gaine thermo-rétractable : ce sera plus fiable et moins cher que des connecteurs.

Sinon, oui, il existe sûrement des connecteurs 4 fils "verrouillables", même si je n'ai pas en tête une référence précise à conseiller


 

Je ne suis pas sûr de comprendre ce que tu entends quand tu dis que le losange est un mécanisme universel. Si tu veux dire qu'il peut décrire n'importe quelle trajectoire (dans la limite des dimensions), c'est vrai, c'est un mécanisme à 2 DOF (ie 2 degrés de libertés). Mais la même chose est vraie pour n'importe quel quadrilatère (tu peux prendre un parallélograme ou même un quadrilatère quelconque, ça marchera encore). C'est aussi le cas pour une jambe série.  Dans tous les cas, tu peux décrire n'importe quelle forme.

Néanmoins, il y a plusieurs différences, qui font que selon les cas, l'un ou l'autre des mécanismes sera le plus pertinent :

- le montage mécanique (encombrement, placement des actionneurs, rigidité, ...)

- l'amplitude du mouvement dans chaque direction (le losange est symétrique, avec d'autres mécanismes tu peux obtenir des amplitudes plus grandes vers l'arrière que vers l'avant, par exemple)

- si tu utilises les mêmes moteurs, selon le mécanisme, tu aura plus ou moins de vitesse et de couple à chaque partie de la trajectoire. Donc selon les parties de la trajectoire qui nécessitent de la vitesse, du couple ou de la force (dans une certaine direction) au niveau du pied, certains mécanismes seront plus pertinents que d'autres

Enfin, on peut rajouter l'élégance et la simplicité qu'on peut obtenir si on arrive a se passer d'un des moteurs, comme c'est le cas du stranbeest. On peut alors aller encore plus loin, et coupler toutes les pattes ensemble sur un seul moteur : on a alors un quadrupède qui avance (en ligne droite) avec un unique moteur : on se passe donc complètement d'asservissement : l'électronique peut se réduire à un moteur branché directement sur une batterie, sans même un controleur moteur. A noter, que si on veut pouvoir tourner, il faudra au moins un second moteur

Bonsoir,

quelques infos supplémentaires (j'avais uilisé la même puce GPS, juste montée sur un autre PCB (d'ardusimple)):

- les 1 cm de précision, c'est en mode avec correction de données. Le problème, c'est qu'il faut les données de corrections. Pour ça, il vous faut soit une deuxième carte identique pour servir de station de référence (nb : la précision de la première carte dépendra de la précision à laquelle vous connaissez la position de la première), soit récupérer des données de correction via internet (il y a quelques stations de références gratuites, mais bien souvent il vous faudra payer un abonnement)

- les 1cm de précision, c'est en plein champ, avec aucun obstacle qui cache des satellites ou provoque des rebonds du signal. En ville, il vous arrivera régulièrement que l'erreur monte à plusieurs mètres (voir plusieurs dizaines de mètres dans des situations particulièrement défavorables)

- il vous faut prévoir en plus une antenne GPS (de préférence de bonne qualité, ça joue pas mal), et de quoi récupérer les données de correction (connection internet, radio ou 4G, selon la source de correction)

Pour résumer, c'est une belle techno, mais assez capricieuse. Si vous avez besoin d'une precision de quelques centimètres en continue, alors il vous faudra vous limiter aux terrains parfaitement dégagés (en plein champ en plaine, sur un bateau au milieu d'un lac, ...)

Bonjour,

j'ai jamais utilisé ce robot, mais c'est un robot à base d'arduino, donc si tu peux nous mettre les liens vers la notice de montage et les instructions, je peux essayer de t'aider.

En plus de ça, j'aurais quelques questions pour orienter les recherches :

- est-ce que le téléversement du programme se passe bien (ie l'IDE Arduino affiche "téléversement terminé" et pas une erreur)?

- est-ce que tu as des LED qui clignotent sur l'arduino?

- c'est quoi to niveau de connaissance en électronique? et en programmation? (comme ça, j'adapterais mes explications à ton niveau)

- est-ce que tu possède un multimètre ou un voltmètre? Ou à défaut une LED et une résistance de entre 150 et 500 ohms?

Bonne journée

Sandro

Bonsoir,

Tu as regroupé et renommé des variables globales : c'est bien, ça améliore déjà un petit peu la lisibilité.

Une autre action toute simple pour gagner en lisibilité est de corriger l'indentation. A la main, ce serait très long, mais l'IDE arduino t'offre une solution très rapide : tu sélectionne tout (Ctrl+A), puis tu fais outils/formatage automatique. Et voilà!

La prochaine grande étape vas être de progressivement se passer de la majorité de ces variables globales.

Vu que c'est une grande tâche, je te propose d'y aller petit à petit.

Je penses qu'un bon début serait de documenter correctement chaque fonction, en rajoutant un "gros" commentaire devant chacune, contenant :

- une description globale de ce que fait la fonction (par exemple "calcule l'heure du lever et du coucher du soleil)

- une description rapide des arguments

- une liste des variables globales lues depuis la fonction (avec explication de leur signification si elle n'est pas évidente)

- une liste des variables globales modifiées depuis la fonction (avec explication de leur signification si elle n'est pas évidente). NB : il peut y avoir des doublons avec la liste précédente.

Pourquoi ce travail?

1) car ça nous rendra beaucoup plus simple la tâche de comprendre ton code

2) car ça permet de facilement voir quelles sont les variables globales lues (qu'il sera probablement utilise de transformer en arguments), et quelles sont les variables globales modifiées (qu'il sera probablement utile de transformer en valeur de retour ou en références)

Pour ta question sur le fait de prendre en compte le "bon" levé et couché de la lune : je penses que c'est faisable, mais si ça te vas, on fera ça après avoir fait le ménage : ce sera plus facile avec un code bien propret (et d'ici là, j'aurais une meilleure vue d’ensemble de ton code pour savoir quoi faire en détail)

Bonne soirée

Sandro

Bonsoir

Pour répondre à Mike118.

Mon système ne génère pas d’énergie. Si tu considère qu’il en génère, alors il faut aussi que tu considère que les systèmes à contrepoids génèrent de l’énergie. Ce qui n’est pas le cas.

Si tu as plus d'énergie qui sort à l'instant t de ton système qu'il n'en entre, alors soit tu génère de l'énergie (ce qui est impossible), soit tu prélève cette énergie sur l'énergie interne du système (énergie cinétique, potentielle de pesanteur, chimique, ...).

Tant qu'il te reste de l'énergie interne au système, il est possible d'avoir plus d'énergie qui sort du système qu'il n'en entre. Ainsi, dans le cas d'un contrepoids, tant qu'il reste de l'énergie potentielle au contrepoids (ie tant qu'il n'est pas tout en bas), il est possible d'avoir plus d'énergie qui sort du système qu'il n'en entre (tu transforme l'énergie potentielle du contrepoids en énergie "utile", par exemple mécanique, en sortie. Par contre, dès que le contrepoids est en bas, plus moyen de retirer de l'énergie à ton système.

Tu peux ensuite remonter ton contrepoids si tu veux, mais ça te demande la même énergie que celle que tu as libérée pour le faire descendre (+ les pertes).

Donc au final, tu peut "créer" de l’énergie utile pendant un court laps de temps (en consommant de l'énergie potentielle), mais si tu veux recommencer, il te faut recharger l'énergie potentielle, ce qui te nécessite de l'énergie.
 

Pour répondre à Sandro.

Si j’ai bien compris ta démonstration et que je l’applique aux systèmes à contrepoids.

Je prends S= (moteur + système à contrepoids)

J’applique le même raisonnement, je devrais donc arriver au même résultat. Ce qui voudrait dire que les systèmes à contrepoids serait un échec ce qui n’est pas le cas.

Je continue mes explications pour lever, il me semble, une éventuelle incompréhension.

Sur un système à contrepoids, sur un temps court, tu veux avoir une libération d'énergie.

Supposons que pendant une durée t1 (le temps de la descente du contrepoids), on arrive à libérer une énergie utile E1

Ensuite, deux possibilités : on remonte le contrepoids a sa position initiale : cela nécessite un apport d'énergie énergie E2>=E1 : une fois le contrepoids remonté, on a récupéré E1 utile mais consommé E2 à apporter : au final, on a du injecter au moins autant d'énergie dans le système que ce qu'on récupère : on ne produit donc pas d'énergie.

Seconde possibilité, le contrepoids reste en bas. On a récupéré une énergie utile E1 (finie), mais l'énergie potentielle du contrepoids est consommée. On a simplement transformée l'énergie interne en énergie utile. A noter que c'est nullement en contradiction avec mon affirmation que Pmoy=0 (rappel, Pmoy est la moyenne sur un temps infini de la puissance sortante - la puissance entrante). De 0 à t1, on a une puissance moyenne P1=E1/t1>=0 qui sort du système. Mais ensuite, plus rien ne sort. Donc la puissance moyenne sur un temps infini est Pmoy = (t1*P1 + 0)/(t1 + infini) = 0.

Prenons un cas plus concret : un ascenseur constitué d'une cabine de masse M, et d'un contrepoids de même masse M.

La hauteur totale est H, la cabine est à la hauteur h et le contrepoids à la hauteur H-h.

Un moteur sert à mettre en mouvement l’ascenseur dans un sens ou dans l'autre.

Supposons un cas idéal (ie pas de frottements).

Prenons le système S1 constitué de la cabine et du contrepoids.

L'énergie interne du système est :

Einterne= Epp_cabine + Epp_contrepoids + Ec_cabine + Ec_contrepoids, où Epp est l'énergie potentielle de pesanteur et Ec l'énergie cinétique (correspondant à une vitesse v).

= M * g* h + M*g*(H-h) + 0.5*M*v² + 0.5*M*(-v)²

= M * g * H + Mv²

On remarquera que la partie énergie potentielle (M*g*H) est constante, donc on n'a pas besoin d'apporter d'énergie pour compenser le fait que la cabine monter ou descende. Le moteur doit seulement fournir l'énergie pour accélérer l’ascenseur (Mv²) et compenser les frottements.

Pour freiner l’ascenseur, on peut utiliser le moteur en mode générateur (si l'électronique le supporte), et retransformer l'énergie cinétique (Mv²) en électricité (modulo les pertes). Une solution plus bourrine est de faire forcer le moteur contre le mouvement de l’ascenseur (pour freiner plus vite) : dans ce cas, on consomme encore de l'électricité, qu'on transforme en chaleur.

Donc excepté le peu d'énergie nécessaire pour compenser le frottement et accélérer/freiner l'ascenseur, on peut le déplacer "gratuitement". Pourquoi, tout simplement car l'énergie reste dans le système, et s'échange simplement entre les deux sous-parties (cabine et contrepoids).

A noter que dans l'absolut, le contrepoids est inutile : on pourrait utiliser le moteur pour remonter l’ascenseur (nécessite un moteur bien plus gros), ce qui consomme pas mal d'énergie (précisément M*g*H + pertes), qui excepté les pertes est intégralement convertie en énergie potentielle de pesanteur. On peut ensuite récupérer cette énergie potentielle de pesanteur en utilisant un générateur pour freiner la descente, ce qui permet de récupérer intégralement l'énergie potentielle M*g*H (modulo les pertes).

Donc pourquoi s'embêter avec un contrepoids "qui ne sert à rien"? Car un moteur plus petit (qui doit seulement soulever les personnes et accélérer la cabine) est beaucoup moins cher. De plus, utiliser un moteur en générateur complique beaucoup l'électronique, et les pertes sont plus élevées.

Pour résumer :

1) si tu veux "équilibrer" un mouvement, tu dois déplacer de l'énergie au sein de ton système, et elle ne soit pas en sortir. En général, ce déplacement se fera entre une énergie cinétique (mouvement) et une énergie potentielle. Donc si tu n'as pas une forme de stockage d'énergie dans ton système, alors tu n'arrivera pas à avoir une équilibrage "actif"

2) les systèmes de contrepoids, de ressorts, ... Sont complètement inutiles pour produire de l'énergie. Ils permettent seulement de ne pas consommer inutilement de l'énergie dans un système cyclique.

3) En gros, si tu as un système cyclique (horloge, ascenceur + contrepoids ...), alors en utilisant adroitement des moyens de stockage d'énergie (ressort, contrepoids, ...), tu peux n'avoir besoin que de l'énergie pour compenser les pertes. Par contre, tu ne pourra en aucun cas t'en servir pour extraire de l'énergie). Par exemple, si dans ton ascenseur il y a uniquement des gens/objets qui le prennent en montant, tu consommera en plus des pertes une énergie m*g*H (ooù m est la masse des personnes qui monter) . Impossible donc de t'en servir pour monter du poids que tu utiliserais ensuite pour produire de l'énergie en le faisant redescendre : au final, toute l'énergie que tu gagnerais en faisant descendre tes objets aurait d'abord été nécessaire pour les monter (sans parler des pertes).

je vais refaire un programme juste avec la fonction lune comme ça je pourrais te donner le code complet .

Si le problème persiste, alors un programme avec juste la fonction lune est utile (à condition que tu ait vérifié auparavent que tu ais le même comportement avec le nouveau programme).

Si tu as envie qu'on parte sur un "ménage" dans ton code, alors un programme avec juste la lune n'est pas très utile, il vaut mieux le programme complet. Si ça te gène que ça face trop long dans le message, tu peux mettre ton code (avec sa balise code comme tu fais d'habitude) à l'intérieur d'une balise "spoiler" (que tu trouvera depuis le troisième icone de la première ligne ("BBCodes Spéciaux")
 

Bonjour,

pourquoi est-ce que tu as modifié la fonction calculPwm de Mike (à part la petite correction que j'ai suggérée)? Est-ce qu'elle ne marchait pas? Ou est-ce qu'il lui manquait une fonctionnalité?

Je penses que si tu remplace ta fonction calculPwm par celle de Mike (en remplaçant le "<" par "<=") alors ton problème sera probablement résolut.

Dans l'état actuel des choses, je penses qu'il y a plein d'erreurs :

- TimeMins est un argument de la fonction calculPwm, il ne faut donc pas le recalculer depuis l'intérieur de la fonction (encore moins définir une autre variable TimeMins à l'intérieur de celle-ci : tu te retrouve avec deux variables qui ont le même nom, ce qui rend très difficile de s'y retrouver)

- tu calcules minuit_lunaire_Hour comme la moyenne de deux variables en minutes

- tu as deux variables identiques : minuitLunaire et minuit_lunaire_Min

- tu manipule plein de variable globales : si je me souviens bien, on s'était mis d'accord qu'il ne fallait pas utiliser de variables globales (je te conseilles vivement de n'utiliser aucune variable globale, ça rend le programme très dur à déboguer et à lire par d'autres personnes). Pour ma part, j'en utilise quasi-jamais, même pour de très gros programmes (si j'en ai 5 dans un programme de plusieurs milliers de lignes, c'est en général que j'ai mal organisé mon programme).

PS : si tu souhaites de l'aide de ma part après ce bug précis, alors une fois ce bug résolu, poste ton code en entier, et je t'aiderais à enlever les variables globales et à restructurer proprement ton code. En effet, si le reste de ton code est à l'image du bout que tu vient de poster, alors sans un peu de ménage, ce sera extrêmement chronophage d'y trouver d'autres bugs (et pour être honnête, j'ai mieux à faire que de chercher des bugs dans un code mal organiser; en revanche, je t'aiderais volontiers à mieux écrire ton code, et à développer une méthodologie pour que tu fasses moins d'erreurs et que tu puisses plus facilement les trouver par toi même)

Bonsoir,

j'ai un peu regardé, mais sans trouver pour l'instant.

Par contre, deux éléments pourraient être utiles pour trouver le problème :

1) à quelle heure a tu vu le "121" aujourd'hui? Est-ce que tu as noté les valeurs à d'autres horaires?

2) Est-ce que tu pourrais s'il te plait poster le code complet (ou du moins toutes les parties concernant l'affichage de la lune)? Car tu parles d'indiquer "121", alors que dans le code #200 de Mike, il n'y a aucun print de la valeur du PWM : tu as donc du modifier le code. Il est donc possible que tu y ait introduit une différence qui joue un role.

Enfin, j'ai trouvé une petite erreur dans le code #20, qui n'explique en rien ton problème : à "midi" pile, le PWM est 0 (au lieu de 255). La raison est que les comparaisons avec midi sont des comparaisons strictes, du coup midi pile n'entre dans aucun des "if".

La solution est de considérer midi pile comme faisant encore partie de la phase montante :

  // phase montante
  if (currentTime > riseTime && currentTime <= midi) {    //remplacement de < par <=
    pwm = map( currentTime, riseTime, midi, 0, 255);
  }

Bonjour,

il y a en effet des case qui sont identiques.

ça vient du fait qu'on ne regarde qu'une partie de la frame, qui est constituée comme suit (cf https://github.com/T...duct Manual.pdf, section 5.3) :
0 -> 0x59 (vérifié par Mike)
1 -> 0x59 (vérifié par Mike)

2 -> distL : bits de poids faible de la distance : lu par Mike

3 -> distH : bits de poids fort de la distance : lu par Mike

4 et 5 -> force du signal (ignoré par Mike, sauf pour le contrôle du checksum)

6 et 7 -> température interne (ignoré par Mike sauf pour le contrôle du checksum)

8 -> checksum : Mike vérifie qu'elle est correcte

Vu que Mike ignore la force du signal et la température, c'est normal que le code est le même pour les case 4 à 7 : il consiste simplement à prendre en compte l'octet dans la checksum et à passer à l'octet suivant. Si jamais tu t'intéresse à la force du signal ou à la température du signal, alors il faudra modifier les case correspondants sur l'exemple des case 2 et 3 (distance)

Bonsoir,

Pour la couleur des axes, j'avais pris l'axe bleu pour l'entrée et le brun pour la sortie. Si le bun est l'entrée, alors le rapport est 1/2 au lieu de 2/1 (mais le raisonnement reste le même)

Pour tes schémas, l'erreur apparaît au n°2 :

Prenons comme grandeur de référence l'engrenage bleu, dont on vas dire qu'il a tourné de pi/2 autour de l'axe vertical (et par conséquent pi/2 autour de son centre).

Par contre, l'engrenage brun aura tourné du double (2*pi/2=pi). Pourquoi?

Si l'engrenage bleu tournait uniquement autour de l'axe vertical (en étant "bloqué" en rotation autour de son centre), alors ça entrainerait une rotation de pi/2 de l'engrenage brun.

Mais en plus, l'engrenage bleu tourne de pi/2 autour de son centre, ce qui ajoute une rotation supplémentaire de pi/2 à l'engrenage brun : l'engrenage brun aura donc tourné au total de pi/2+pi/2 = pi.

Bonjour,

c'est vrai que c'est pas super intuitif.

Voici le raisonnement "avec les mains" pour me convaincre que la sortie tourne plus vite que l'entrée :

Si on enlève le pignon fixe, et qu'on bloque la rotation des roues bleus autour de l'axe "vertical", alors la sortie tournera à la même vitesse que l'entrée, ie w.

Si on regarde juste le pignon fixe et les deux roues bleues, on se rand compte facilement qu'elles tournent à vitesse w.

Une rotation à vitesse w des roues bleues (si elles ne se déplacent pas) donne une vitesse w à la sortie.

Ici, on a la superposition des deux phénomènes : les roues bleues tournent, et tournent autour de l'axe horizontal : on a donc superposition des deux effets (qui vont dans le même sens). Il est donc logique que la sortie tourne plus vite que w

Bonjour,

Sur la photo n°3, en haut à gauche, sous le fil rouge, il y a un composant avec marqué à coté (si je devine bien) : F1 / 230Vac / 1.0A

Il y a de très fortes chances que ce soit un fusible.

Du coup vérifie si le fusible à cramé (utilise le multimètre pour mesurer la résistance entre les deux bornes : si elle est quasiment 0, alors le fusible est intact. Si elle est plus grande que quelques ohms, alors le fusible a cramé : dans ce cas, il y a de bonnes chances que changer le fusible suffise à réparer ton chargeur. Attention, ne fais pas de tests en changeant le fusible avant qu'on en ait discuté plus en avant : il y a d'autres tests qu'il faudra effectuer avant une remise en tension (il est possible qu'il y ait un court circuit en plus si le fusible a été trop long à se déclencher).

Si ce n'est pas le fusible, alors je ne penses pas qu'on puisse raisonnablement te guider dans la réparation du PCB (ça impliquerait des tests sous tensions, ce qui avec du 220V peut être mortel en cas d'erreur)

Bonsoir,

Vu que tu sembles ne pas vouloir nous dire où tu veux en venir, voici quelques considérations théoriques :

1) Cas d'un système fermé (ie rien ne rentre ou sort, ni énergie ni matière) : la quantité d’énergie totale dans le système (tous types confondus : électrique, cinétique, potentielle, thermique, ...) reste constante. Il peut y avoir des transformations entre plusieurs types d'énergie (par exemple entre cinétique et potentielle de pesanteur, dans le cas d'un contre poids)

En théorie, un mouvement "équilibré" comme tu dis serait possible (par exemple une horloge qui ne s'arrêterait jamais, un ascenseur (qui ne transporte personne) avec son contre poids qui oscille monte et descend sans jamais s'arrêter, ...) . En pratique, il y a des pertes (frottements entre autres) qui font qu'une partie de l'énergie se transforme en énergie thermique, qu'on ne peut pas entièrement retransformer en énergie cinétique : le mouvement finira donc quand même par s'arrêter.

Par contre, par définition, rien ne sort d'un système fermé : il n'est donc pas possible d'en extraire de l'énergie (sinon ce n'est plus un système fermé).

A noter que ce n'est pas pour autant qu'un système fermé n'a pas d'intérêt. Il serait par exemple, en théorie, envisageable de concevoir une horloge qui tourne pendant 1000 ans avec une seule pile. On pourrait même envisager un ordinateur qui puisse tourner quasi indéfiniment avec une simple pile (en supposant que l'écran ne soit pas lumineux et qu'il n'alimente aucun périphérique).

2) Cas d'un système ouvert (ie on considère un volume donné, dans lequel peut entrer et sortir de la matière et de l'énergie) : la masse du système est la masse initiale du système + la masse qui est entrée - la masse qui est sortie. De même, l'énergie du système est l'énergie initiale du système + l'énergie qui est entrée - l'énergie qui est sortie. (nb : pour être plus précis, il peut y avoir destruction de masse accompagnée de création d'énergie (par exemple fission de l'uranium) ou l'inverse : je ne penses pas que ce cas soit ce qui t'intéresse, donc on vas considérer qu'il n'y a ni création ni destruction de masse).

Par conséquent, si tu veux retirer de l'énergie d'un système, celle-ci doit soit être initialement dans le système (par exemple de l’essence que tu brûle, ou une pile initialement pleine), soit être injecté dans ton système (par exemple quand tu fais le plein de la voiture, tu y injecte de l'énergie potentielle chimique). Un volume donné ne contenant qu'une quantité finie d'énergie, tu ne pourra jamais extraire une quantité infinie d'énergie de ton système si elle n'y rentre pas sous une forme ou une autre.

Donc sur le temps long, si tu veux un système qui te fournisse de l'énergie en continue, alors il faut lui injecter la même quantité d'énergie (ou plus si tu considère qu'il y a une partie de l’énergie qui s’échappe sans que tu la récupère). Le mieux que tu puisses espérer est donc un rendement de 100%, c'est-à dire que toute l'énergie que tu mets dans le système sous une forme pas directement utile (par exemple l’essence dans la voiture, l'énergie potentielle de l'eau dans un barrage, ...) soit transformée en énergie utile (mouvement de ta voiture, électricité, ...).

Donc pour conclure :

- pour un système fermé, on peut tendre vers un fonctionnement "sans fin". Il y a là de gros potentiels (je penses en particulier aux ordinateurs, dont il devrait être possible en théorie de réduire drastiquement la consommation électrique)

- pour un système ouvert : on peut tendre vers un rendement unitaire, c'est-à dire que toute l'énergie injecté dans le système en ressorte sous une forme utile. Pour cela, il peut être utile "d'équilibrer" les parties qui restent en permanence dans le système. Par exemple, pour un ascenseur, on mets un contrepoids pour équilibrer le poids de la nacelle : il ne faut donc fournir que l'énergie nécessaire pour déplacer les passagers (et compenser les pertes, qu'on peut tenter de faire tendre vers 0) ; on pourrait faire un ascenseur sans contre poids : ça marcherait, mais il faudrait fournir l'énergie pour monter la nacelle à chaque fois, sans pouvoir la récupérer de manière utile à la descente.

Enfin, pour ce que tu évoquais à un moment "d'équilibrage" sans limite de distance : tu as quelques méthodes de stockage d'énergie qui n'impliquent pas à priori une limite de distance, par exemple deux aimants que tu peux écarter autant que tu veux. Mais ce n'est pas pour autant que tu pourra y stocker une énergie infinie.

Ce que j'entendais par 6 "contacts" par bouton, c'est "interrupteurs" (d'un point de vue électrique) qui peuvent être ouverts ou fermés (mais commandés par un unique bouton d'un point de vue mécanique).