[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).

[1] 10 Février 2020 Aujourd’hui, on a pris la plus grande partie du cours à décider quel projet on voulait faire. Il s’agissait initialement du Sewgay, mais on a abandonné le projet à cause de notre budget qui ne convenait pas. Nous avons donc décidé de faire une voiture téléguidé. Pour le reste du cours, on a travaillé principalement sur le Google Docs en commençant une description du projet.

-Xavier Lagacé

[2] 13 Février 2020 Maintenant que nous avons décidé quel projet nous voulons faire, nous avons terminé la description initiale du projet commencée au dernier cours. Celle-ci nous a permis de se donner une bonne idée des principaux défis que ce projet représente. De plus, nous avons aussi entamer une liste des pièces qui seront nécessaires à la réalisation de ce projet ainsi que les prix de ceux-ci.

-Xavier Lagacé

[3] 17 Février 2020 Dans le troisième cours, on a été plus en profondeur sur la liste des pièces. En effet, on a réussi à réduire le coût du projet en regardant si on avait déjà des pièces à nos maisons. Comme de fait, Isaac avait 3 batteries de voitures télécommandées qui pourront nous servir à alimenter nos 4 moteurs. Cependant, nous craignons que ces batteries de 7.2V et de 750mAh ne fournissent pas assez de courant. Plus de détails à venir à ce sujet lorsque nous recevrons les moteurs…

-Xavier Lagacé

[4] 20 Février 2020 Aujourd’hui, j’ai continué de documenter le Google Docs avec des images et et j’ai approfondie les explications du problème de différentiel après m’être informé à l’aide de vidéos sur YouTube. Pendant ce temps, Isaac faisait la bibliographie de toutes nos sources. Cela comprend la liste des pièces, les images utilisées et la vidéo sur les différentiels. De plus, on a trouvée une vidéo qui montre comment connecter un appareil Android à un Arduino. Cela réglerait notre problème de télécommande pour diriger le véhicule.

-Xavier Lagacé

[5] 24 Février 2020 Aujourd’hui, on a plus fait de documentation que de recherche. Je me suis occupé de modifier le site WordPress, de le mettre à jour et de rattraper notre léger retard dans les blogs alors qu’Isaac est en train de faire le diagramme de Gantt. Nous sommes aussi en train de réfléchir à une façon d’obtenir 4 encodeurs afin de pouvoir savoir la vitesse de chaque roue individuellement. La solution qu’on a trouvée pour l’instant consiste à démonter une vieille souris qui traîne chez Isaac afin de voir si l’encodeur de la roulette ferait l’affaire. Si c’est le cas, nous irions à l’Éco-Centre de Saint-Jérôme pour chercher 3 autres vieilles souris. Plus de détails sur les encodeurs à venir.

-Xavier Lagacé

[6] 03 Mars 2020 Isaac a démontée sa vieille souris et la molette était exactement ce que l’on pensait: un encodeur lumineux. Cela dit, il nous semble compliqué de prendre un tel circuit et de le transférer. Il faudra donc tenter d’en construire un nous mêmes. Il faudra par contre trouver une roulette moins précise, car celle de la souris avait trop de fentes. Un solution serait de briser quelques fentes… Mis à part l’encodeur, nous avons pensé a une deuxième façon de déterminer la vitesse des roues qui est à l’aide d’un transistor de Hall. Nous avons passé le reste du cours à travailler sur l’analyse préliminaire.

-Xavier Lagacé

[7] 05 Mars 2020 Nous avons fini la faisabilité et donc l’analyse préliminaire. Nous pouvons donc passer à l’étape de construction du véhicule. J’ai aussi fait des recherche sur la viabilité des détecteurs d’effet Hall. Nous pensions pouvoir en faire un avec simplement une feuille d’aluminium carrée à travers laquelle nous passerions un courant en connectant deux fils sur deux coins opposés. Puis, nous connecterions deux autres fils aux extrémités et mesurerions la différence de potentiel entre les deux pour déterminer s’il y a présence d’un champs magnétique.

-Isaac Doré

[10] 10 Mars 2020 Afin de réduire les coûts, construire notre propre châssis au lieu d’en acheter un déjà fabriqué est une des meilleures façons d’y parvenir. Nous avons réflechi à plusieurs options et le bois semble la meilleure d’entre elles puisque j’ai déjà de l’expérience pour travailler le bois, j’ai déjà les machines afin de le travailler et puisque le bois est très abordable. J’irai donc en acheter durant la semaine de relâche.

-Xavier Lagacé

[12] 15 Mars 2020 Aujourd’hui, j’ai décidé de faire un dessin technique avant de faire quoi que ce soit d’autre. J’ai décidé cela puisque ça me permet d’avoir une bien meilleure idée de la quantitée de bois que j’aurai besoin et la coupe du bois sera beaucoup moins remplie d’essais-erreurs. Pour faire le dessin technique, ma copine m’a donné une feuille de dessin technique qu’ils utilisent dans son cours de technique en Génie Industriel. Il s’agit d’une feuille quadrillée 0.5 x 0.5 qui est assez large afin de pouvoir y faire une vue du dessus et une vue de côté. J’aurais aussi pu faire une vue de face, mais je n’y voyais pas le but puisque tout ce qui avait à couper était déjà très clair avec les 2 plans. Il ne faut pas oublier que ce dessin n’était pas une obligation scolaire, mais simplement un plan pour m’aider à être plus efficace dans ma coupe. Je mettrai une photo de ce dessin technique dans le document word de l’analyse du projet puisque j’ignore comment le faire sur WordPress.

-Xavier Lagacé

[13] 16 Mars 2020 Très petite mise à jour. Aujourd’hui, j’ai terminé le dessin technique une bonne fois pour tout et je suis allé acheter du bois au Home Dépôt. Pour le dessin, j’ai décidé de faire le châssis un petit peu épais puisqu’il est plus facile d’enlever du bois par après que d’en rajouter. On pourra toujours refaire des recoupes afin d’enlever le bois en trop par après.

-Xavier Lagacé

[14] 18 Mars 2020 J’ai commencé à couper mes planches. Le châssis a super bien été, mais la direction me semble plus compliquée que prévue. En effet, les bouts de bois que je voulais couper pour mettre dans les trous que j’ai percés avec ma perceuse à colonne frottaients trop à mon goût. Ils étaient rugueux et j’avais peur que cela fasse forcer le servo-moteur de la direction inutilement. J’aurais pu le sabler, mais je n’avais pas envi de perdre mon temps, donc à la place j’ai pris des morceaux de brochette en bamboo qui étaient dans ma cuisine puisqu’ils sont déjà très solides et très lisses. Je suis rendu à trouver une façon de faire tenir en place ces bâtons. Pour l’instant, ma meilleure idée est de mettre de la colle-chaude. Cependant, cela causerait du frottement sur le bois. Il faudra voir si le frottement est trop important.

[15] 9 Avril 2020 Nous revoila! Le projet a été mis sur pause pendant un bon bout de temps à cause de tout ce qui se passe dans le monde! Il n’était plus vraiment clair si les études allaient continuer ou si tout arrêtait; on avait donc préféré d’attendre des nouvelles. Bref, il y a des bonnes et des mauvaises nouvelles. Pour les bonnes nouvelles, les études continues en ligne et donc, notre projet recommence enfin! Cependant, les mauvaises nouvelles sont que le cégep ne peut plus nous commander de pièces encore une fois à cause du virus. Cela nous met un sacré bâton dans les roues puisque le projet dépendait entièrement de cela… Pour remédier à cette solution, Isaac va expliquer dans le prochain blog ce qu’on s’est entendus de faire avec notre enseignant. En gros résumé, nous allons simuler la voiture sur Unity puisque cela se travaille beaucoup mieux en virtuel qu’en réel avec la distancation sociale. Cela implique que tout ce que j’ai fais avec le châssis en bois et ce qu’Isaac à fait avec les encodeurs auront servi à rien! Ce n’est pas grave, au moins on a appris des choses! 🙂

-Xavier Lagacé

[17] 14 Avril 2020 Aujourd’hui, beaucoup de recherches. Isaac va les expliquer dans ses blogs. Ce qui a le plus ressorti de nos recherches était qu’il fallait choisir entre le constraint-car et le raycast-car pour choisir le comportement de la suspension. Nous avons choisit le raycast-car puisque le constraint-car peut devenir compliqué assez rapidement et que nos échéanciers sont rendus très minces. De son côté, Isaac commence à programmer nos recherches, créer une map dans laquel nous pourrons rouler la voiture. De mon côté, j’ai commencé à documenter nos recherches dans notre fichier word que nous remettrons à notre enseignant.

-Xavier Lagacé

[21] 17 Avril 2020 Aujourd’hui il ne s’est pas passé grand chose mis-à-part que j’ai continué de documenter nos recherches. Isaac m’a aussi montrer ce qu’il a fait jusqu’à présent. Le programme avance très bien, la voiture tourne, la suspension fonctionne, le centre de masse semble réaliste. La prochaine étape est de faire tourner les roues (présentement, la voiture avance, mais les roues ne tournent pas) et faire freiner la voiture. Pendant qu’Isaac fait cela, moi je commence à faire des recherches à propos de la friction des organes mécaniques d’une voiture. On entend par là de tenter de comprendre comment que se dissipe la puissance du moteur dans les organes (Trouver une façon de calculer la différence entre les chevaux vapeurs au vilebrequin du moteur et les chevaux vapeurs qui sont transmis aux roues), car forcément ces chevaux perdus disparaissent quelque part dans les organes mécanique. Mon hypothèse pour l’instant est principalement dans la transmission et les ratios d’engrenages. Une fois que j’aurai mieux compris le sujet, je tenterai de programmer un tel détail dans notre simulation.

-Xavier Lagacé

[28] 1 Mai 2020 Dans les deux semaines qui se sont écoulées, j’ai finalement décidé de faire le moteur avant le frottement des organes; j’ai trouvé beaucoup plus intéressant pour la simulation de commencer par cela et de faire le frottement si j’ai le temps. J’ai passé la première semaine et demi à faire des recherches à propos du fonctionnement d’un moteur à combustion interne et j’ai pris le temps de comprendre toutes le variantes qui existent. (Beaucoup plus de détails dans la documentation détaillé que j’ai faite). En résumé, suite à mes apprentissages, j’ai décidé de m’orienter vers un moteur à combustion interne, atmosphérique, à injection indirecte et moderne (sans carburateur). Ce choix a été fait puisque ce type de moteur est beaucoup plus prévisible et fonctionne avec des formules et calculs qui sont plus de notre niveau. Malheureusement, une bonne partie de mes recherches n’auront servi à rien puisque rendu à un certain point, j’ai réalisé qu’il serait impossible de simuler l’admission dans un si petit laps de temps (échéancier le 14 mai 2020). Nous avons donc opté pour le même type de simulation de moteur que dans les jeux de course sur console: avec une courbe de puissance moteur en relation avec le régime moteur de celui-ci. Cela est très efficace, fiable et est une très bonne solution à notre problème d’échéancier. Le seul désavantage est que cette façon de faire ne prend pas en compte la richesse de l’air en oxygène et donc, l’altitude à laquelle le moteur fonctionne.

-Xavier Lagacé

[29] 8 mai 2020 Une fois que le moteur fonctionnait bien, j’ai passé à la transmission qui est la prochaine pièce entre le vilebrequin du moteur et les roues. Pour la transmission, j’ai négligé la perte de force qui est nécessaire pour faire tourner les engrenages. (J’y reviendrai si j’ai le temps une fois le différentiel terminé). J’ai regardé un bon nombre de vidéo et animations qui montrent son fonctionnement et j’ai décidé d’opter pour la transmission automatique puisque le joueur n’aura pas besoin de gérer un embrayage et que le véhicule peut être embrayé à l’arrêt sans que le moteur cale. J’ai pris les ratios d’engrenages d’un Toyota Tacoma trouvé sur internet et dans le code, nous faisons que multiplier le ratio d’engrenages avec le travail émis par le moteur étant donné que le travail est multiplié dans un jeu d’engrenage. (Cette notion a été vue dans nos cours de physique). La vitesse de reculons n’a pas encore été programmée.

-Xavier Lagacé

[30] 14 mai 2020 La date de remise à été reportée au 17 mai 2020. Cependant, je n’ai pas eu le temps d’avancer beaucoup plus le projet puisque j’ai pris le temps que j’avais depuis le 8 mai afin de finir ma documentation, citer les sources et expliquer le fonctionnement du code de la transmission et du moteur pour la remise du 14 mai. Cependant, j’ai tout de même avancé mes recherches à propos du différentiel. J’ai jugé qu’il est important de le programmer et de l’instaurer puisqu’il possède lui aussi un ratio d’engrenage et il vient donc lui aussi multiplier le travail avant d’être distribué aux roues. Chose qui manquait à notre voiture puisqu’il était clair qu’elle manquait de torque pour avancer. Je n’aurai donc pas le temps de programmer les pertes dues au frottement des organes mécaniques (nous garderons pour principe que le monde est parfait et que rien de frotte). Cependant, la voiture offre tout de même un très bon ressenti de réalisme et est agréable à conduire. Je suis content du résultat malgré tout ce que nous avons simplifié et considéré comme étant parfait! J’ai beaucoup appris. Je mettrai un dernier blog lorsque le différentiel sera réussi. (Pour l’instant on a simplement multiplié notre travail par 3, soit une valeur de ratio de différentiel réaliste trouvée sur internet.)

-Xavier Lagacé

[31] 16 mai 2020 C’est le grand jour! J’ai terminé le différentiel, mais j’ai dû faire des compromis. En effet, puisque je n’ai pas eu le temps de faire des recherches à propos du fonctionnement d’un transfer case, je n’ai pas mis l’option de faire une voiture 4 roues motrices. En effet, dans notre cas, la voiture est traction (roues avant propulsées). Je suis tout de même satisfait du résultat sachant que j’ai dû aussi programmer une flexplate donc j’ignorais l’existence dans une transmission automatique. En effet, cette pièce était essentiel puisqu’elle nous permettait de calculer le régime moteur lorsque l’embrayage du convertisseur de couple n’était pas encore embrayée. (Parce qu’avant l’embrayage qui se fait à environ 85-90% du ratio de différence de vitesse entre l’impulseur et la turbine du convertisseur de couple, le moteur peut tourner indépendamment des roues).

-Xavier Lagacé