Sandro

À part le problème qu'une batterie sera vide avant les autres (qui n'a pas l'air de trop te déranger), un autre problème est que chaque moteur aura une tension de batterie différente, donc tournera a une vitesse différente pour le même PWM. Si tu as un vrai contrôle en vitesse de chaque roue (par exemple avec un encodeur), alors ça ne posera pas trop de problème. Si par contre tu comandes en boucle ouverte, alors ton robot partira sur un coté ou sur l'autre dès qu'une batterie atteindra une tension plus basse que les autres.

Tant que la différence de tension est faible, les 2 roues du même coté devraient continuer à tourner à la même vitesse (celle avec la tension de batterie forçant plus). Si la différence est importante, tu risques d'avoir les 2 roues qui tournent à des vitesses différentes (donc glissent sur le sol), ce qui use rapidement les pneus.


Mettre des batteries non identiques et potentiellement avec des tensions différentes en parallèle est une très mauvaise idée (en gros, tu crées un court circuit entre la batterie la plus chargée et la moins chargée). Si (et seulement si) une des batteries est capable à elle seule de fournir tout le courant nécessaire, alors tu peux les mettre en parallèle via des diodes : tu vas alors décharger la plus chargée jusqu'à ce qu'elle ait la même tension que la seconde plus chargée, puis tu vas tirer du courant sur les 2 jusqu'à ce que la tension baisse au niveau de la 3ième plus chargée, puis tu utilisera 3 batteries, ... NB : dans la vrai vie, le partage est un peu plus complexe, car les batteries ont une résistance interne, donc leur tension "externe" diminue avec le courant : la batterie 2 commencera donc à fournir un peu de courant quand la batterie 1 ne sera pas encore descendu au niveau de charge de la batterie 2 (à cause de la chute de tension due au courant délivré par la batterie 1).
Si tu veux creuser cette piste, préviens moi, et je peux détailler plus.

Quelques éléments à prendre en compte :

- la simulation de réseaux de neurones "par couches" (ie l'information ne vas que dans un sens, aucune mémoire) est relativement facile. C'est ce qui est utilisé par la majorité des réseaux de neurones artificiels (par exemple pour du traitement d'image, de la reconnaissance d'objets, ...). Ce genre de calcul se laisse très bien paralléliser sur un GPU, ou même sur des circuits plus ou moins dédiés, comme les "tensor core" sur les GPUs récentes de Nvidia, qui sont conçu pour effectuer rapidement (et sur beaucoup d'éléments en même temps) les multiplications de matrices et additions nécessaires pour les réseaux de neurones artificiels.

- si le "cerveau" fonctionne en partie en réseau de neurones par couches, le système de locomotion est plutôt basé sur des réseaux de neurones oscillants ("en boucle"). Il suffit de quelques neurones pour simuler un muscle qui se tend et se détend en rythme. Avec quelques neurones de plus, on peut synchroniser le mouvement avec un autre oscillateur (par exemple celui d'un autre muscle). De même, avec quelques neurones supplémentaires, on peut ajouter une entrée de "contrôle" (par exemple pour déclencher le mouvement ou l'arrêter). De mémoire, avec entre 100 et 500 neurones, on avait réussi à obtenir (en simulation) la marche d'un quadrupède (lors d'un de mes cours sur la robotique bio-inspirée).

- en terme de simulation, les réseaux de neurones oscillants (ou toute autre architecture autre qu'en couches) est beaucoup plus coûteuse, car on passe en temps continue. Au lieu d'avoir simplement à faire des multiplications et des additions, il faut maintenant résoudre des équations différentielles non linéaires. Là, je ne suis pas sûr qu'on sache aujourd'hui simuler des dizaines ou des centaines de milliers de neurones en temps réel sur un processeur remarquable dans un insecte.

Pour la 2ième option : tu peux simplement mettre 2 interrupteurs en butée de ta roue, et gérer la butée en logiciel. Si tu ajoutes un encodeur sur ton moteur (probablement plus facile que sur l'axe de la roue), alors les butées te permettront de facilement calibrer le "zéro" de l'orientation de ta roue (car quand tu alumes, tu n'as aucune idée de la position absolue de ta roue, à moins d'utiliser un potentiomètre (peu précis) ou un encodeur absolut (souvent soit peu précis, soit cher))

For the leg motors :
At 3:36, they say (in german) than the robot is equipped with 2 motors (those for jumping) developed by a spin-off company from ETH-Z. They just say they are strong electrical motors without specifying the type.
I suspect (but without proof), that those motors are developed by ANYbotics, which is an ETH-Z spinoff listed among their sponsors, that develops legged robots, including some capable of jumping (and if I remeber well a presentation they gave in 2018, they told us they developped their own motors).

So those are very likely not hoverboard/electric scooters motors, but motors designed specifically for legged robots (and therefore probably quite expensive)

For the wheel motors :
I found no information about their nature

On s'est également tourné vers l'ATtiny85 pour tester une autre approche qu'avec celle de l'ATMEGA328 car on utilisait seulement 9 broches sur les 28 disponible.

Si les broches vous suffisent, pourquoi pas. Mais le nombre de broches n'est pas vraiment lié ni au prix, ni à la taille.
Si on regarde chez digikey, l'ATtiny85-20PU est à 1.58€ : https://www.digikey....gAYAFAVRAF0BfIA
Un micro-controleur alternatif, avec 20 pins, à 0.90€, et qui fait seulement 3x3mm : https://www.digikey....3F3U6TR/3087895

 

Pour le condensateur entre VCC et GND du NRF24L01+ on a vue que c'est assez important à faire pour stabiliser l'alimentation.

Je suis d'accord, il en fondra probablement un, surtout si vous utilisez une pile avec un faible courant max.
NB : le choix du condensateur, en plus de la capacité, devra également prendre en compte le courant de fuite (ou la résistance de fuite). Selon les modèles de condensateurs, le courant de fuite risque d'être non négligeable pour votre application

Les 2 résistances entre qui divise la tension pour PB3 c'est pour mesurer l'état de la batterie. Peut-être une info qu'on voudra communiquer de temps à autre (voir plus bas)

 

Comme évoqué plus haut, 10k + 20k sont des valeurs beaucoup trop faibles (trop de courant de fuite). Par contre, si vous montez trop haut, l'appel de courant sur le pin de lATtiny vas fausser le diviseur de tension : la solution est soit de mettre un condensateur en parallèle avec R2, d'ajouter un ampli-op en suiveur (mais attention à la consommation de celui-ci : il en faudra probablement un spécial pour basse consomamtion et/ou avec un pin qui permet de le mettre en veille
 

D'autre point à prendre en compte :

• l'ATtiny à un réveil tous les 7 ou 8 secondes (j'ai pas encore bien saisi ça dans la datasheet) donc on va pas réveiller le microcontroleur toutes les 5min exactement mais plutôt tout les x cycles de réveil (par exemple 37 cycles de 8 secondes = 4min56)

Il n'y a que les humains qui se soucient des minutes. Si ça ne perturbe pas l'interface utilisateur, choisissez n'importe quelle durée qui vous convient
 

• Potentiel ajout d'un transistor pour éteindre complètement le capteur de distance car il est trop gourmand.

très probablement nécessaire avec la plupart des capteurs qui n'ont pas de mode veille intégré
 

La stratégie au niveau du code :

• Mise en veille de tous les éléments, seulement le timer interne de l'ATtiny85 qui fonctionne
• Au bout de 5 minute, réveil des composants, calcul de la distance et envoie au poste central (selon si la distance a changé)
• Réponse du poste central pour la réception et rendort le module pour 5 minutes
• Cas où il la cantine est fermé Réponse du poste central pour la réception et rendort le module pour 20 heures (environ) tout en demandant une estimation de la batterie au prochain réveil.

Je suggère que l'unité centrale indique la durée de rendormissement souhaitée si la cantine est fermée : si c'est les vacances, on peut demander bien plus que 20h, si la demande est faite à 4h du matin, alors ça sert à rien d'activer le capteur dessuite, mais il n'y a pas le temps pour dormir 20h. NB : il vaut mieux toujours sous-estimer un peu la durée du sommeil pour prendre en compte la tolérance de l'horloge du capteur. Au pire on lui dit de se rendormir pour 30 minutes. Mais ce serait dommage qu'il se réveille 30 minutes trop tard.

 

On a pris note un peu de la consommation, on est pas sûr à 100% pour nos calculs car c'est un truc qu'on a jamais fait en cours (bizarrement on ne calcul jamais l'autonomie lol). Tout est détaillé dans un Excel ou on remarque que si on gère pas bien le HC-SR04, on a une autonomie de 20 jours 

Ça ne me surprends absolument pas qu'avec le HC-SR04 actif en permanance l'autonomie soit muavaise (j'ai pas regardé sa consommation). Je vous conseille de faire aussi le calcul de sa consomation en l'activant juste le temps de faire la mesure (passage en mode alimenté + énergie nécessaire pour faire la mesure), pour voir si c'est acceptable sur l'année ou pas.