Blog

[8] 7 mars 2020 Je suis allé acheter l’équipement dont j’avais besoin pour fabriquer un prototype d’encodeur, soit un fer à souder, de l’étain et un multimètre. J’ai commencé par me pratiquer en retirant un simple bouton en faisant fondre la soudure à l’aide du fer à souder et en prenant un fil de cuivre pour gratter l’étain fondu. Par la suite, je me suis servi d’une méthode similaire pour retirer l’émetteur. La seule différence est que, plutôt que de gratter (puisque les soudure étaient trop petites), j’ai fait fondre les deux soudures en même temps pour retirer la composante sans avoir à les enlever. Je n’ai pas encore réussi à retirer le récepteur puisque celui-ci est très petit et a 3 «pin». Donc aucune de mes méthodes ne fonctionnent.

-Isaac Doré

[9] 8 mars 2020 J’ai réussi à déloger le récepteur infrarouge de la souris. J’ai pu tester que celui-ci marchait bien en mesurant la différence de potentiel entre les «pins» pendant que j’appuyais sur les boutons d’une manette de télévision. Tel que prévu, celle-ci augmentait.

-Isaac Doré

[11] 11 mars 2020 À l’aide d’un «breadboard», j’ai testé comment les «Analog inputs» fonctionne sur le arduino et j’ai pu assembler un circuit qui alimentait l’émetteur et le récepteur infrarouge et qui retournait un signal lisible dans la console. Cependant, puisque je n’ai pas mis de résistance dans la branche du circuit avec l’émetteur, celui-ci a, au bout de quelques secondes, brièvement émit de la lumière visible, puis, a cessé de fonctionner.

-Isaac Doré

[16] 9 avril 2020 À cause de la pandémie de la COVID-19, le Cégèp ne pourra pas nous acheter les pièces nécessaires à notre projet. Nous nous sommes donc entendu avec notre professeur pour changer de projet. Il nous faudra faire une simulation de voiture dans Unity en ne se servant que de rigidbodies, de colliders et, bien sur, de notre propre code.

-Isaac Doré

[18] 14 avril 2020 Selon mes recherches, il existe 2 types de voiture en jeu vidéo: le raycast-car et le constraint-car. Je commencerai par faire les deux en même temps et nous choisirons par la suite celui qui est le plus adapté au projet. Le raycast-car est le type de voiture le plus utilisé car il est moins coûteux au niveau des calculs. Dans un raycast-car, plutôt que d’avoir des roues, nous émmetons un raycast (d’où le nom) vers le sol qui nous permet de déterminer le point de contact entre la roue et le sol ainsi que la normale de la surface touchée et la vitesse relative entre la roue et la surface. Ces informations nous permettent de faire, de manière approximative, tous les calculs de physique requis pour faire une voiture réaliste. Un constraint-car est une voiture faites de pièces étant chacune simulée par le physics-engine qui intéragissent entre elles selon des contraintes. Donc, dans un constraint-car, la roue est elle-même un objet attaché au chassis par une contrainte qui applique une force sur la roue si elle se rapproche de son point d’encrage. L’avantage de cette méthode est qu’elle est beaucoup moins approximative et que nous avons beaucoup d’«effets gratuits». C’est-à-dire que beaucoup d’effets qu’on observe sur une vrai voiture seraient présent dû simplement à l’intéraction des contraintes. Cependant, j’admet pencher vers le raycast-car puisque la simulation se ferait à partir de notre code et nous n’aurons pas à régler des problèmes qui ont comme origine cette boîte noire qu’est le physics-engine.

-Isaac Doré

[19] 15 avril 2020 La suspension est la première chose à faire puisqu’elle calcule la force appliquée sur les roue. Il faut prendre ce résultat pour faire les autres calculs. J’ai implémenter la suspension sur le constraint-car et le raycast-car. J’ai commencé par le premier. Pour celui-ci, j’aurais pu utiliser simplement le spring joint déjà présent dans Unity, cependant, cela aurait brisé la contraintes que nous nous étions donné de ne nous servir que des rigidbodies et des colliders. Or, si cette contrainte n’est pas respectée, cela rend le projet complètement trivial. Donc j’ai créé une contrainte «suspension» qui fait trois chose: limiter la roue à un axe prédéterminé, bloquer la roue si elle est trop éloignée et appliquer une force sur la roue et le chassi si ceux-ci se rapproche. La magnitude de cette force est donnée simplement par F=k|L-x| où k est la constante de rappel, L est la longueur normale du ressort et x est la distance entre la roue et sont point d’accroche. La direction de cette force est simplement donnée par la direction de l’axe mentionné plus haut. La partie du code qui limite la roue à un axe fonctionnait en projettant le vecteur vitesse relative (entre la roue et son point d’accroche) et le vecteur position relative (idem) sur le vecteur qui représente l’axe à l’aide d’un produit scalaire. Or, cette méthode change la vitesse et la position des roues avec une force apparente sortie de nulle part et brise par conséquent toutes les lois de Newton. Pour remédier à ce problème j’ai multiplié les vecteurs déplacement et changement de vitesse (le déplacement et le changement de vitesse qui résulte de cette projection) par -1, puis, par le ratio masse de la roue/masse du chassis et j’ai appliqué ces transformations au châssis. Cela aura pour effet de conserver le momentum total de la voiture (aussi, cela aura l’«effet gratuit» que si un objet pousse sur la roue, cette force sera transférée à la voiture). Par la suite, il me faut programmer l’ammortissement puisque, dans l’état actuel du code, une voiture lachée de 1m rebondit à une hauteur de 1m. Pour ce faire, j’ai tout simplement appliqué un changement de vitesse constant à ma roue dans la direction opposée de sa vitesse actuelle. (Isaac du futur ici pour mentionner que ce que j’ai fait correspond à un ammortissement linéaire. Un vrai ressort a un ammortissement expotentiel, c’est-à-dire qu’il perd un certain pourcentage de sa vitesse à chaque seconde plutôt qu’une certaine vitesse fixe). Par la suite j’ai fait la suspension du raycast-car. Celle-ci fonctionne en faisant un raycast à partir du point d’accroche dans la direction donnée par l’axe. Ce raycast nous donne alors le point de contact entre la roue et le sol et nous permet de calculer la magnitude de la force avec la même formule que pour l’autre suspension. La direction de la force est, encore une fois, donnée par l’axe. Cette force n’est bien sûr appliquée qu’au châssis. Cette méthode peut donner, dans certaine condition une force sortie de nulle part et il me faudra rectifier ce problème.

-Isaac Doré

[20] 16 avril 2020 Pour règler le problème de la force sortie de nulle part, j’ai donné une masse aux roues et j’ai fait que la voiture recalcule le centre de masse et que sa position soit affectée lorsque celui-ci se déplace. Donc, si le centre de masse ce déplace de 10cm vers le bas, la voiture est remontée de 10cm pour garder le centre de masse à la bonne place. Aussi j’ai trouvé un autre exemple d’«effet gratuit» : https://cstj365-my.sharepoint.com/:v:/g/personal/1873499_cstj_qc_ca/EQA_zKLA0lFItbn_4jjBHL0BPI1GS3sDuUGRIZSgFn7lpg?e=9Vt0ML. À gauche il y a le constraint-car, à droite le raycast-car, lorsque le constraint-car frappe le sol à l’envers, les roues continuent puisqu’elles sont des objets avec une inertie. J’ai aussi modifier l’amortissement pour qu’il soit plus réaliste. Désormais, la vitesse relative entre la roue et son point d’encrage est multipliée par un nombre entre 0 (amortissement total) et 1 (aucun amortissement) à chaque timstep (l’intervale de temps entre deux calculs du physics-engine). Je n’ai pas implementé cela sur le constraint-car puisque nous avons choisi de faire le raycast-car.

-Isaac Doré

[22] 17 avril 2020 Aujourd’hui j’ai travaillé sur la friction des roues. Mon but était de programmer la friction de façon à ce qu’il n’y en ait aucune dans la direction où la roue pointe mais qu’il y en ait vers le côté. Ainsi cela simulerait une roue qui roule. Le plus gros problème était de savoir quand appliquer la friction statique et quand appliquer la friction dynamique. À première vue, le problème semble simple puisque la friction statique ne s’applique que lorsque les surfaces qui se frottent sont immobiles l’une par rapport à l’autre. Cependant, aucun physics-engine n’est assez précis pour rendre un objet complètement immobile. Il faut donc trouver un meilleur moyen de basculer entre la friction dynamique et statique. Ma solution était de calculer la force nécessaire pour annuler la vitesse de la voiture dans la direction où il y a de la friction et de comparer cette force à la force maximale que la friction statique peut appliquer. Si la première est plus grande que la seconde, j’applique la friction dynamique, sinon j’applique la friction statique. Puisque la friction est calculée, Il sera trivial d’implémenter les virages.

-Isaac Doré

[23] 18 avril 2020 J’ai implementé les virages. Puisque la direction dans laquelle la friction des roues est appliquée dépend de leur orientation, il suffit de faire littéralement tourner les roues pour effectuer un virage. J’ai cependant découvert un problème qui, je crois, provient de la friction statique. Je ne sais pas encore pourquoi, mais, lorsque j’effectue un virage trop serré, la voiture, plutôt que de déraper, se met à faire des tonneaux. Je règlerai ce problème plus tard.

-Isaac Doré

[24] 19 avril 2020 J’ai implémenté la rotation des roues et l’ajout de moment de force aux roues (torque). Pour cela, il m’a fallu ajouter un moment d’inertie à la roue (calculé à partir de sa masse et de son rayon en assumant un cylindre parfait) et modifier une bonne partie du code qui gère la friction. Les modifications à la friction sont dues au fait que la roue peut désormais tourner indépendamment de la vitesse du véhicule (donc si on applique trop de moment de force sur la roue elle peut «spiner dans l’beurre»). Par contre, la stratégie pour calculer la friction reste la même, c’est-à-dire, calculer la force nécessaire pour annuler la vitesse de la voiture et de la roue et la comparer à la force de frottement statique.

-Isaac Doré

[25] 20 avril 2020 Je suis allé consulter différentes sources pour me faire une idée des valeures réelles de différentes variables sur une voiture. Je me suis, par la suite, servi de ces variables pour les mettre dans ma simulation et voir si celle-ci est réaliste. J’avais espoir que mon problème où la voiture fait des tonneaux trop facilement disparaîtrait si je mettais les bonnes valeures. Ce n’était pas le cas. J’en conclu donc que le problème est bel et bien dans mes calculs. Par la suite, j’ai augmenté le moment d’inertie de la voiture puisque Unity assume une distribution uniforme de la masse alors que, puisque l’intérieur de la voiture est vide, celle-ci est concentré sur les parois extérieur de la voiture. Bien qu’il n’ait pas règlé le problème, j’ai conservé ce changement.

-Isaac Doré

[26] 21 avril 2020 J’ai trouvé la source de mon erreur: le calcul de la friction statique dépend du nombre de roues au sol (pour la répartition du poid). Or, dans mes calculs, j’avais pris le nombre de roues total. Donc, dans la plupart des cas, il n’y avait aucun problème. Cependant, dès qu’une roue décollait du sol (comme dans un virage serré) cela avait l’effet de décupler la force de friction statique, ce qui faisait souvent basculer la voiture.

[27] 30 avril 2020 J’ai complété les freins. Pour se faire, j’ai tout simplement appliqué le même principe qu’avec la friction des roues au sol. C’est-à-dire, calculer la force de friction statique entre la plaquette de frein (brake-pad) et le disque et, si celle-ci est suffisante, bloquer la roue, sinon, appliquer la friction dynamique. Cependant, le code de la friction entre la roue et le sol ne prennais pas en compte la friction dans la direction de la roue si celle-ci ne servait pas à la faire tourner. Il m’a donc fallu introduire quelques lignes de code pour y remédier. Il m’a fallu aussi introduire une nouvelle variable représentant le couple associé à la force de friction statique. Cette variable permet de bloquer ou débloquer la roue selon le moment de force appliqué sur celle-ci (soit par le moteur et la friction avec le sol).