Trajectoire en arc de cercle véritable

Le plus célèbre des concours de robotique français dédié à tous les jeunes amateurs de nouvelles technologies.
[EN FRANCAIS UNIQUEMENT - ONLY IN FRENCH]
User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Trajectoire en arc de cercle véritable

Post by sikularobotik » Sat 11 Feb 2017, 14:31

Voici une première leçon que nous avons apprise en travaillant sur ce sujet.

Notre odométrie avait une erreur de l'ordre de 5° sur 100 tours (0.014%) et moins de 5mm longitudinal sur 15m (0.033%)
Néanmoins, cela ne semblait pas assez précis pour des trajectoires qui ne sont pas en lignes brisées.
Alors nous essayons d'améliorer les choses.

A) Asymétrie des roues
Gargamel nous rappelait sur ce forum (il y a quelques années) qu'un écart relatif infime de 1/1000e sur le diamètre des roues provoquait des trajectoires sur de très grands cercles. Néanmoins pas assez grands puisque qu'on pouvait observer un écart de 6cm latéral au bout de 3m de déplacement rectiligne (robot avec 30cm de voie). Il y a aussi d'autres écarts qui peuvent s'ajouter à ce phénomène mais qui sont corrigés par le même facteur.
Nous avons pu voir à l'œuvre cette correction dans un couloir de 15m où le robot ne tapait plus contre le mur après correction.

B) Précision des nombres à virgule flottante
La plupart de notre code utilise des nombres à virgule flottante car c'est commode et le processeur dispose d'une unité de calcul dédiée à ces nombres. Nous utilisions des nombres en simple précision (type float) car avec 23+1 bits de mantisse, cela donne entre 7 et 9 chiffres significatifs dans le système décimal et une précision en micromètres est bien en dessous des erreurs de mesure.
Or cette réflexion est trop superficielle.
Par exemple, pour la conversion de tics vers mètres, notre coefficient est entre 25150 et 25151. Le mètre ne tombe pas tout à fait juste et les décimales sont importantes car cette valeur sera utilisée pour calculer la vitesse qui sera à son tour intégrée. En consommant 5 chiffres significatifs sur la partie entière, il reste peu de place aux décimales. De plus, ce nombre sera multiplié par le coefficient d'asymétrie évoqué plus haut (1.000386 pour la roue droite par exemple) et là la précision devient encore plus insuffisante.
Nous sommes donc en train de passer certaines variables en double précision (type double) pour restaurer ces bits afin de réduire les pertes par calcul.

C) Intégration
Réalisons une simple intégration (dite intégration devancée) en sommant: I += df; (I l'intégrale et df l'élément à intégrer à ce pas de temps : le pas de temps est 1s pour simplifier l'explication) Imaginons maintenant que nous avancions incroyablement à 0.1 m/s à chaque échantillon, toujours pour simplifier. En exagérant, cela donne un code comme celui-ci :

Code: Select all

#include <stdio.h>

int main() {
	const float increment = 0.1f;
	const unsigned int loops = 2e8;
	float wanted = increment * loops;
	float naive_sum = 0.0f;
	unsigned int ui;

	for (ui = 0; ui < loops; ++ui) {
		naive_sum += increment;
	}

	printf("Wanted: %f\n", wanted);
	printf("Naive: %f (error: %f %f%%)\n", naive_sum, wanted - naive_sum, 100*(wanted - naive_sum)/wanted);

	return 0;
}
et le résultat suivant :
Wanted: 20000000.000000
Naive: 2097152.000000 (error: 17902848.000000 89.514236%)
L'odométrie compte 2'097km au lieu de 20'000km (grosso-modo Laval-Minsk au lieu de Biarritz-Wellington). Il y a une sacrée différence, mais est-ce pertinent à notre échelle ?
Pour le voir, nous appliquons l'algorithme de Kahan qui permet de réduire drastiquement cette erreur ; et effectivement en intégrant avec correction, le robot voit des écarts qu'il ne prenait pas en compte auparavant.

D) Pouillèmes
Ce point est pour rappeler que ces raffinements ne sont absolument pas nécessaires pour tous et que sans ces ajustements notre odométrie était suffisante pour la coupe.

Prochaine étape: régler l'odométrie avec ces corrections et voir si l'asservissement souffre de maux similaires
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

arno
PMI
Posts: 700
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Trajectoire en arc de cercle véritable

Post by arno » Sat 11 Feb 2017, 15:48

sikularobotik wrote:Nous utilisions des nombres en simple précision (type float) car avec 23+1 bits de mantisse, cela donne entre 7 et 9 chiffres significatifs dans le système décimal et une précision en micromètres est bien en dessous des erreurs de mesure.
Or cette réflexion est trop superficielle.
Je ne suis pas surpris par ces résultats.
On utilise depuis des années une résolution en nm de nos variables liées à l'odométrie pour justement pouvoir faire un réglage correct. On travaille en entiers 32 bits aussi, donc ce qui donne une meilleur précision relative qu'un float (tant qu'on évite le débordement).
Et une intégration en entier est exacte (à la résolution près), pas de risque de perdre les dernières décimales comme avec un float.
Après, si tu as accès à des flottants doubles, un U32 tient dedans sans être tronqué, donc tu as les avantages de ne pas avoir à te poser trop de questions quand faire le calcul sur un U64 pour éviter les débordements, tout en ayant plus de précision qu'un flottant simple (et même qu'un U32).

Donc exactement les mêmes résultats que tes conclusions. Sauf que nous on a déjà fait ça pour faire marcher correctement les lignes droites, pas les cercles. Il est intéressant de voir que cela ne vous génait pas jusque là avec des lignes droites ! Surement lié aux différences de rapports de réductions, taille des roues, nombre d'impulsions par tour des roues codeuses entre nos robots.

Courage pour la suite, ça s'annonce bien !

User avatar
wix
PMI
Posts: 509
Joined: Sun 17 Sep 2006, 22:35

Re: Trajectoire en arc de cercle véritable

Post by wix » Sun 12 Feb 2017, 20:13

les erreurs de trajectoire ne sont pas compensées ; mais comme l'asservissement est assez performant, l'erreur est très faible.
Ce n'est plus un asservissement sur les erreurs ne sont pas compensées ^^ (on parle bien du niveau trajectoire et non du niveau polaire qui est asservi). Dit autrement une boucle ouverte est suffisante car il n'y a que peu d'erreur introduite à ce niveau ce qui est certainement du à une bonne méca et à un "I" dans l'asserv polaire éfficace qui joue un rôle de "P" à ce niveau.
Qui fait le malin............... tombe dans le ravin
(Equipe Ard, suivez nous sur Twitter : )

User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Trajectoire en arc de cercle véritable

Post by sikularobotik » Tue 18 Jul 2017, 20:10

Pour faire suite, après les leçons dont je vous ai fait part, le robot n'est passé entre mes mains qu'à la coupe.
C'est inévitable avec une équipe dispersée géographiquement comme la nôtre.
Donc je n'ai pas beaucoup avancé/expérimenté entre temps.

Néanmoins, nous avions effectué les correctifs dans le code et j'ai pu avoir quelques minutes pour tester à La Roche-sur-Yon : à pleine bourre, le cercle est beau et le décalage minime.
D'ailleurs, nous nous sommes servis des cercles pour calculer les constantes de géométrie : à 20 tours de 50 cm de rayon, ça donne une distance parcourue de plus de 60m qu'on connaît avec une bonne précision (les quelques millimètres de décalage du robot sont relégués loin dans les chiffres significatifs). Pratique et économe en place.

Par ailleurs, nous nous sommes aperçus (après la coupe) d'un problème bien plus impactant. À l'occasion d'un changement de carte de contrôle l'an dernier, nous avons introduit un bug hardware : les pull-up sur les codeurs sont BEAUCOUP trop élevées (donc le robot perd des tics et pas le même nombre selon sa charge)
Cela expliquerait bien des cas étranges que nous avions aperçu sans y prêter vraiment attention.
J'emploie le conditionnel car, à cause de l'éloignement à nouveau, nous ne pourrons vérifier que quand le robot sera arrivé entre les mains opportunes.

Une fois ce nouveau soucis réparé, nous pourrons aller plus loin dans les tests, probablement courant octobre (oui, nous n'avons pas les mêmes échelles de temps que la plupart des équipes).
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Trajectoire en arc de cercle véritable

Post by sikularobotik » Tue 18 Jul 2017, 20:41

Aussi comme promis, voici les équations pour calculer nos trajectoires de consignes polaires.

Données:
- angle, l'angle à parcourir sur l'arc (algébrique [sens trigonométrique], en radians),
- rayon, le rayon du cercle (algébrique [éloignement du centre de rotation du robot sur son axe perpendiculaire au déplacement], en mètres),
- E, la demi-entraxe des roues (constante géométrique positive, en mètres),
- vmax, la vitesse max de la « roue extérieure » (valeur absolue, en m/s)
- amax, l'accélération max de la « roue extérieure » (valeur absolue, en m/s²)

On notera que angle et rayon étant algébriques, il existe plusieurs cas :
- angle > 0 et rayon > 0, le robot part en avant à gauche,
- angle < 0 et rayon > 0, le robot part en arrière à gauche,
- angle > 0 et rayon < 0, le robot part en arrière à droite,
- angle < 0 et rayon < 0, le robot part en avant à droite,
- angle > 0 et rayon = 0, le robot tourne sur lui-même en sens trigonométrique
- angle < 0 et rayon = 0, le robot tourne sur lui-même en sens horaire
- angle = 0, le robot ne bouge pas

N'arrivant pas à s'en sortir avec ces cas issus des conventions mathématiques, les utilisateurs ont préféré effectuer un changement de coordonnées en plus haut niveau.

Calculs (|⋅| est la valeur absolue) :
- L'angle à parcourir est trivialement... angle
- La distance à parcourir est simplement angle × rayon [oui, on multiplie aussi les signes]
- La vitesse maximale (trajectoire de l'asservissement linéaire) est vmax × |rayon| ÷ (|rayon| + E) en valeur absolue
- L'accélération maximale (trajectoire de l'asservissement linéaire) est amax × |rayon| ÷ (|rayon| + E) en valeur absolue
- La vitesse maximale (trajectoire de l'asservissement angulaire) est vmax ÷ (|rayon| + E) en valeur absolue
- L'accélération maximale (trajectoire de l'asservissement angulaire) est amax ÷ (|rayon| + E) en valeur absolue

Le gros avantage de ces équations vis-à-vis des autres énoncées auparavant dans le fil de discussion est que ça ne diverge en aucun point. Il n'y a pas de zone dégénérée, et ça, c'est vraiment super cool.
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

User avatar
PF
Posts: 22
Joined: Wed 19 Jul 2017, 16:15
Location: Toulouse
Contact:

Re: Trajectoire en arc de cercle véritable

Post by PF » Fri 28 Jul 2017, 20:28

Je me permets d'intégrer la conversation car c'est un sujet qui m'intéresse. Je suis un programmeur de l'équipe INTech Senpaï qui a participé à la coupe de France avec le moon rover, un robot à 4 roues (qui ne peut donc pas tourner sur lui-même). Notre robot est obligé de se déplacer avec des trajectoires courbes.

La vidéo d'un de nos matchs : https://www.youtube.com/watch?v=RRG_A8C ... .be&t=6781

Notre robot fait une recherche de chemin qui trouve un chemin en clothoïde (donc pas de discontinuité d'accélération) puis parcourt ce chemin. Mais surtout, et c'est là où je voulais en venir, il est asservi en trajectoire. Donc ce n'est pas une boucle ouverte comme vous en avez parlé précédemment.

Notre idée a été d'avoir un asservissement en courbure (l'inverse du rayon de courbure). Si on est trop à gauche de la trajectoire, on augmente la courbure et on se dirige un peu plus vers la droite. L'asservissement prend aussi en compte l'erreur d'orientation.

Les détails sont disponibles dans ce document que j'ai écrit il y a un moment, à la page 13 : https://techthetroll.files.wordpress.co ... courbe.pdf

Comme vous pouvez le voir sur la vidéo, on a une assez bonne précision : on se cale précisément contre les cratères. Nos performances étaient plutôt limitées de l'odométrie (on passe plusieurs fois par la bascule, ça aide pas…).

Si cela vous intéresse, je peux entrer dans les détails :)
INTech (2013-2015)
TechTheTroll (2016)
INTech Senpaï (2017-2018)

Prix de l'innovation 2017 :D
Un pathfinding courbe dont les trajectoires sont facilement suivables (librairie Java) : https://github.com/PFGimenez/The-Kraken-Pathfinding

arno
PMI
Posts: 700
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Trajectoire en arc de cercle véritable

Post by arno » Fri 28 Jul 2017, 22:33

PF wrote:
Fri 28 Jul 2017, 20:28
Les détails sont disponibles dans ce document que j'ai écrit il y a un moment, à la page 13 : https://techthetroll.files.wordpress.co ... courbe.pdf
Merci pour le partage ! Document très intéressant !

J'ai juste survolé pour le moment (au sens où j'ai lu le texte mais pas les formules :) ), mais j'ai déjà un point de discussion 8) .

Tout d'abord, j'ai bien aimé comment tu écartes les courbes de Bézier pour "des raisons de difficultés mathématiques", quand on voit les formules des clothoïdes :D

Visiblement, le point qui te pose problème est "il n’est pas forcément facile de planifier un chemin en cherchant des points de contrôle qui peuvent être dans des obstacles.". Ce qui est illustré page 19 (Figure 5.2).

Je ne sais pas si tu la connais, mais une des propriétés géniales de courbes de Bézier est que la courbe reste dans l'enveloppe convexe de ses points de contrôles. C'est probablement pas très clair dis comme ça, mais la figure suivante l'illustre: http://www.engr.mun.ca/~dfriis/cadkey/p ... bezier.gif
Donc, si lors du pathfinding, tu peux découper des zones "libres" convexes, par exemple sous forme de rectangles : toute courbe de Bézier dont les points de contrôle sont contenus dans ce rectangle va elle même rester dans ce rectangle. Donc pour l'exemple de la courbe figure 5.2 de ton document, il faudrait définir un rectangle sous le premier obstacle, un entre les deux obstacles et un au dessus du dernier obstacle. Si ces rectangles se chevauchent, alors on peux choisir comme premier/dernier point de contrôle de chaque courbe de Bézier un point dans la zone appartenant à 2 rectangles, ce qui permet de les joindre en garantissant que la courbe totale restera dans la zone sans obstacle.
C'est quelque chose qui est par exemple illustré dans la publi suivante : http://infolab.stanford.edu/pub/cstr/re ... 5-1537.pdf en page 93/94 (105/106 du pdf), à la différence que c'est avec des cercles et non des rectangles (mais les deux sont convexe donc c’est équivalent).

Je ne sais pas si ça peux t’intéresser ou pas, vu que vos clothoïdes ont l'air de bien marcher !

Dans tous les cas, je fais passer le lien de ton doc à mes coéquipiers, ça devrait les intéresser aussi. Encore merci !

User avatar
PF
Posts: 22
Joined: Wed 19 Jul 2017, 16:15
Location: Toulouse
Contact:

Re: Trajectoire en arc de cercle véritable

Post by PF » Fri 28 Jul 2017, 23:32

Merci de ton retour !

À vrai dire, j'ai changé d'avis depuis l'écriture de ce document ^^ pour donner un peu de contexte, ce document a été écrit pour la coupe 2016, et clairement ce n'était pas au point à ce moment-là (notre robot ne roulait pas…). Nous avons beaucoup appris cette année, et je vais encore améliorer les choses pour l'année prochaine.

Du coup, pour en revenir aux courbes de Bézier, dans la version du moon rover le pathfinding en utilise. C'est même nécessaire, car avec des clothoïdes on ne peut pas choisir où on arrive (on lance juste différentes clothoïdes), or on veut souvent pouvoir arriver à un endroit précis (contre un cratère pour le dernier règlement), ce qui est permis par les courbes de Bézier (les courbes de Bézier permettent facilement d'imposer des contraintes sur le départ ou l'arrivée, que ce soit en position, en orientation ou en courbure).

Concernant ma phrase "il n’est pas forcément facile de planifier un chemin en cherchant des points de contrôle qui peuvent être dans des obstacles", ce que je voulais dire c'est qu'il est difficile de trouver les bons points de contrôle quand ils sont dans des obstacles (même quand la courbe de Bézier est elle-même ne croise pas les obstacles !). Merci d'ailleurs de m'avoir rappelé cette propriété qu'ont les courbes de Bézier de toujours rester dans l'enveloppe convexe, ça me permettra de vérifier facilement s'il y a collision ou non.

Si cela t'intéresse, je travaille sur une librairie en java qui est une adaptation du code de pathfinding qui tournait sur le moon rover (c'est encore expérimental !) : https://github.com/PFGimenez/The-Kraken-Pathfinding . Le rover avait une raspi 3 et le pathfinding prenait 30s pour un trajet long (le terrain était très encombré). De fait, le rover se souvenait des trajectoires calculées d'un match à l'autre. On n'avait qu'à le faire rouler par terre pour qu'il apprenne plein de trajectoires à réutiliser en match. C'est encore trop lent pour en usage en plein match mais j'ai bon espoir de diviser par 10 ce temps (il y a encore beaucoup de marge de progression). On travaille aussi sur une petite librairie d'asservissement (cette fois en C++). Pas que l'asservissement soit en lui-même très compliqué, mais on a mis du temps à le mettre au point.

Si j'arrive à me motiver, je pense réécrire le document avec mon expérience de cette année. Si tout se passe bien, en septembre je présente au forum un document tout beau et une lib utilisable facilement =)
INTech (2013-2015)
TechTheTroll (2016)
INTech Senpaï (2017-2018)

Prix de l'innovation 2017 :D
Un pathfinding courbe dont les trajectoires sont facilement suivables (librairie Java) : https://github.com/PFGimenez/The-Kraken-Pathfinding

arno
PMI
Posts: 700
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Trajectoire en arc de cercle véritable

Post by arno » Sat 29 Jul 2017, 01:39

Très intéressant tout ça !
En me promenant sur ton GitHub j'ai vu que vous utilisiez des capteurs VL53L0X de chez ST. C'est sur notre liste de trucs à tester, donc je me permet un rapide hors sujet les concernant : quel est votre retour d'expérience là dessus ? Pas de soucis de brouillage entre eux ou avec la luminosité ambiante ? Pas de matériaux sur lequels la détéction est difficile ? etc. Si ça mérite un sujet à part entière pour ne pas polluer celui ci, dis le moi et j'en recrée un.
De mon côté, je suis plus ou moins en train d'essayer de pondre un algo de suivi des courbes de Bézier. Un collègue à mis en place un asserv polaire sur un châssis à 2 roues (donc avec moins de contraintes que dans le votre) et je pense qu'il y a moyen de s'amuser ! A suivre...

User avatar
PF
Posts: 22
Joined: Wed 19 Jul 2017, 16:15
Location: Toulouse
Contact:

Re: Trajectoire en arc de cercle véritable

Post by PF » Sat 29 Jul 2017, 11:18

Dans INTech Senpaï nous sommes deux : je fais la programmation haut niveau (planification de trajectoire notamment) et l'autre membre (Sylvain, le fondateur) s'occupe de la mécanique + électronique + programmation bas niveau (capteurs, asservissement, etc.).

C'est donc Sylvain qui pourra répondre à tes questions techniques. De mon côté, en tant qu'utilisateur haut niveau de ces capteurs, ils sont vraiment très bien. J'étais habitué aux capteurs ultrasons (SRF-05) et infrarouges (de Sharp). Le VL53L0X est un time-of-flight : il mesure le temps de vol. Il est précis (au millimètre près), très directif (c'est de l'infrarouge) et on n'a jamais eu de problème de détection ou de brouillage entre eux (sauf dans un cas bizarre où le capteur devait détecter un filet et où il donnait des valeurs fausses ; peut-être des phénomènes optiques particuliers ?).

A noter qu'on a utilisé une toute petite plaque de dev de pololu pour l'intégrer à notre robot, vu qu'on n'a pas le matériel nécessaire pour faire du CMS : https://www.pololu.com/product/2490

Je vais demander à Sylvain s'il a le temps de t'écrire une réponse plus détaillée :)
INTech (2013-2015)
TechTheTroll (2016)
INTech Senpaï (2017-2018)

Prix de l'innovation 2017 :D
Un pathfinding courbe dont les trajectoires sont facilement suivables (librairie Java) : https://github.com/PFGimenez/The-Kraken-Pathfinding

User avatar
PF
Posts: 22
Joined: Wed 19 Jul 2017, 16:15
Location: Toulouse
Contact:

Re: Trajectoire en arc de cercle véritable

Post by PF » Sat 29 Jul 2017, 11:20

Concernant l'asservissement, notre future lib d'asservissement en trajectoire courbe s'adapte aussi aux robots à essieu central ! Tout comme le pathfinding, d'ailleurs. Du coup, vous pouvez (si vous en avez envie) avoir un "vrai" asservissement en trajectoire.

Dans tous les cas, tiens-moi au courant ! =)
INTech (2013-2015)
TechTheTroll (2016)
INTech Senpaï (2017-2018)

Prix de l'innovation 2017 :D
Un pathfinding courbe dont les trajectoires sont facilement suivables (librairie Java) : https://github.com/PFGimenez/The-Kraken-Pathfinding

User avatar
wix
PMI
Posts: 509
Joined: Sun 17 Sep 2006, 22:35

Re: Trajectoire en arc de cercle véritable

Post by wix » Tue 01 Aug 2017, 22:25

PF wrote:
Fri 28 Jul 2017, 20:28
Je me permets d'intégrer la conversation car c'est un sujet qui m'intéresse. Je suis un programmeur de l'équipe INTech Senpaï qui a participé à la coupe de France avec le moon rover, un robot à 4 roues (qui ne peut donc pas tourner sur lui-même). Notre robot est obligé de se déplacer avec des trajectoires courbes.

La vidéo d'un de nos matchs : https://www.youtube.com/watch?v=RRG_A8C ... .be&t=6781

Notre robot fait une recherche de chemin qui trouve un chemin en clothoïde (donc pas de discontinuité d'accélération) puis parcourt ce chemin. Mais surtout, et c'est là où je voulais en venir, il est asservi en trajectoire. Donc ce n'est pas une boucle ouverte comme vous en avez parlé précédemment.

Notre idée a été d'avoir un asservissement en courbure (l'inverse du rayon de courbure). Si on est trop à gauche de la trajectoire, on augmente la courbure et on se dirige un peu plus vers la droite. L'asservissement prend aussi en compte l'erreur d'orientation.

Les détails sont disponibles dans ce document que j'ai écrit il y a un moment, à la page 13 : https://techthetroll.files.wordpress.co ... courbe.pdf

Comme vous pouvez le voir sur la vidéo, on a une assez bonne précision : on se cale précisément contre les cratères. Nos performances étaient plutôt limitées de l'odométrie (on passe plusieurs fois par la bascule, ça aide pas…).

Si cela vous intéresse, je peux entrer dans les détails :)
:o Bravo pour le travail, ça fait plaisir de voir un peu de maths dans tout ça. Petite remarque en passant, pour être parfaits, vous pourriez ne pas confondre l'orientation du robot avec l'orientation de la tangente de la trajectoire pour l'étendre à d'autres types de robots ... ;-)
Qui fait le malin............... tombe dans le ravin
(Equipe Ard, suivez nous sur Twitter : )

User avatar
PF
Posts: 22
Joined: Wed 19 Jul 2017, 16:15
Location: Toulouse
Contact:

Re: Trajectoire en arc de cercle véritable

Post by PF » Tue 01 Aug 2017, 22:48

Remarque pertinente, j'en prendrai compte pour la prochaine version du document ! =)
INTech (2013-2015)
TechTheTroll (2016)
INTech Senpaï (2017-2018)

Prix de l'innovation 2017 :D
Un pathfinding courbe dont les trajectoires sont facilement suivables (librairie Java) : https://github.com/PFGimenez/The-Kraken-Pathfinding

Post Reply