Logiciel de gestion de course home made

Ben tout pareil que vous les gars!!
J'ai commencé vers 10 ans aussi. Mon père avait un ami qui avait un ZX81 ou spectrum, je me souviens plus, et cette personne à initier mon père. Ensuite mon père (très vite en fait) à acheter un Amstrad cpc 464 (en fait une copie allemande un schneider 464). Et je m'y suis mis en basic biensur.

Ah la la que de souvenir.
10 print ....
20 goto ...

C'est plein de jeunes sur FSF ...

Ah si on avait gardé ces machines...j'aimerais bien un CPC 6128 à brancher sur le moniteur du PC, juste pour le fun de rejouer à Fire & Forget, le jeu ou on était un chevalier qui devait sauter sur des tombes et qui se retrouvait à poil, et bien, bien d'autres...

Tiens si il existait un émulateur Android ça serait cool sur tablette...je vais déjà chercher un bon émulateur sous WinXp pour mon portable !

(encore du temps de perdu à faire des conneries à cause de FSF...)

Des nouvelles fraiches : ce matin les voitures autonomes à tour variable... CA MARCHE !!!!
Le test est fait sur un petit circuit qui me sert juste pour le développement mais c'est relativement concluant. L'auto freine et accélère correctement.
cool !

Ah j'ai décroché !
Bien que je sois développeur aujourd'hui je n'ai rien eu de tout ça mis à part le MO5 à l'école primaire !!
Je suis un faux geek je ne joue même pas aux jeux vidéos !

dd32 a écrit :
Des nouvelles fraiches : ce matin les voitures autonomes à tour variable... CA MARCHE !!!! Le test est fait sur un petit circuit qui me sert juste pour le développement mais c'est relativement concluant. L'auto freine et accélère correctement. cool !

Waw !! Bravo !
Tu vas coder une IA pour avoir un vrai concurrent !!

Pour le moment on est très loin de l'IA ou alors une IA du genre deux neurones ! :)
Il reste des points de blocage mais bon j'avance.

Bravo ! une IA gérée par ordinateur, la classe !

même avec le décodeur j'en trave queutchi,,, c'est des grands malades

Des nouvelles dd32 à propos de ton logiciel ou pas trop eu le temps d'avancer ?

Salut,

Oui ça avance pas mal du tout même (mais pas encore sur la partie Carrera).
J'ai fait une pause de deux semaines pendant les vacances mais j'ai repris le développement.
J'ai passé un peu de temps à corriger les bugs en utilisant le soft en grandeur nature. J'ai un peu bataillé pour le mode solo mais maintenant ça marche bien.
Je me suis remis sur les pacer variables et la j'ai encore un peu de taff avant d'avoir un truc vraiment bien. Pour moi le soft permet de jouer maintenant il faut que je fasse tout le nécessaire pour qu'il fonctionne sur tous les environnements etc.
J'espère pouvoir faire fournir une version d'essais aux intéressés d'ici 1 mois.

dd32 a écrit :
J'espère pouvoir faire fournir une version d'essais aux intéressés d'ici 1 mois.

trop fort ! bravo ...

dd32 a écrit :
Oui ça avance pas mal du tout même ( Mais pas encore sur la partie Carrera ).

dd32 a écrit :
Salut,

Oui ça avance pas mal du tout même (mais pas encore sur la partie Carrera).
J'ai fait une pause de deux semaines pendant les vacances mais j'ai repris le développement.
J'ai passé un peu de temps à corriger les bugs en utilisant le soft en grandeur nature. J'ai un peu bataillé pour le mode solo mais maintenant ça marche bien.
Je me suis remis sur les pacer variables et la j'ai encore un peu de taff avant d'avoir un truc vraiment bien. Pour moi le soft permet de jouer maintenant il faut que je fasse tout le nécessaire pour qu'il fonctionne sur tous les environnements etc.
J'espère pouvoir faire fournir une version d'essais aux intéressés d'ici 1 mois.

Cool !
Je veux bien être volontaire pour le tester avec ma PB-PRO
Bonne continuation !

PS: j'avais un peu réfléchi à comment on pourrait rajouter l'usure des pneus dans la gestion de course. Si on touche à la puissance ça serait redondant avec l'effet des pannes donc j'ai pensé à ça:

@NNKClinton : t’inquiètes, dès que tout sera fonctionnel sur Scalex, je me mettrais sur la partie Carrera !

@Fretz :
Ta réflexion est intéressante pour la gestion de l'usure des pneus.
Changer le comportement sur l'accélération est tout à fait jouable (reste à trouver la bonne règle), toutefois j'y vois un inconvénient. Sur les petites pistes cela pourrait provoquer des accidents notamment avec des autos nerveuses. Au niveau développement, cela implique de "détecter" une phase d'accélération de sortie de courbe ce n'est pas évident étant donné que tout est en temps réel mais on pourrait envisager un truc du genre "si le delta entre deux informations d'accélération est > à X % alors on est déclenche le patinage". Reste ensuite à spécifier précisément ce qu'est "patinage".
Concernant le rallongement des temps de freinage c'est beaucoup plus simple car j'ai fait une option pour régler le frein (on peut limiter le frein moteur). Du coup il suffirait d'augmenter la limitation du frein au fur et à mesure de l'usure des pneus.

Pour les PitStop, pour l'instant je ne me suis pas trop pris la tête. Un arrêt déclenche la "réparation" et le "refuel" en même temps, plus on reste aux stands plus le refuel et la réparation augmentent, on peut quitter le stand quand on veut même si on est juste à 50 % de fuel.
Je ne sais pas s'il y a une plus valu à différencier les actions aux stands, j'ai peur que ça complexifie la jouabilité pour un gain discutable.

Concernant la PB Pro, je ne sais pas si c'est le même protocole que la C7042, tu sais toi ?

Oui les à-coups vaut mieux oublier
Pour la phase d'accélération je pensais juste à un délai entre l'appui sur la poignée et l'envoi de la puissance pour "simuler" un patinage à l'accélération.
Je pense aussi que ce n'est pas la peine de partir sur des algorithmes tout fous pour après avoir un effet discutable en piste.
Le but est juste d'avoir un effet ressentit à l'usure des pneus et qui devienne handicapant sinon y a pas d'intérêt à s'arrêter.

Pour le freinage ça a l'air plus simple et bien correspondre à la réalité, les distances s'allongent avec l'usure des pneus vu qu'il y a moins de "frein"

T'as raison pour les PIT-STOP, vaut mieux ptet rester simple comme c'est prévu pour une utilisation avec enfants. Peut-être pourrais-tu juste différencier les actions PLEIN/REPARATION avec leur vitesse d'exécution : un plein se fait plus vite que des réparations ?...

Je sais pour l'avoir lu que ce n'est pas le même protocole pour la C7030 (et PB-PRO) et la C7042.
Apriori la vitesse de transfert des infos de puissance et autres est bcp plus élevée sur la C7042 ce qui permet entre autres de faire un frein variable qui n'est pas possible avec la C7030 (c'est tout ou rien).
Ca voudrait dire qu'actuellement ton soft n'est pas compatible avec les anciennes PB6
Il faudrait que tu récupères les sources du protocole c'est ça ?
Bon techniquement ça doit être possible puisque "SSDC V5" propose le choix entre les 3 versions de PowerBase.

dd32 a écrit :
@NNKClinton : T’inquiètes, dès que tout sera fonctionnel sur Scalex, je me mettrais sur la partie Carrera !

NP : J'suis pas inquiet ...

C'est toi le programmeur altruiste et de génie ... Tu développes bien ce que tu veux, comme tu veux, sur ce que tu veux, et au rythme que tu veux ...

Mais après avoir vu ce à quoi tu arrives en tant que "développeur solo" : Je ne comprends plus désormais pourquoi un fabricant doté d'une clientèle, de structures et de moyens financiers tel que CARRERA ( Ou autre ... ) ne se donne même pas la peine d'envisager la création d'un tel soft pour décupler l'intérêt de ses produits ... Quitte à commercialiser cette réalisation !
Surtout que leur bizness en général doit se voir quand même pas mal concurrencé par le jeu vidéo et ses simulations ... Ca laisse pensif !

fretz a écrit :
Pour la phase d'accélération je pensais juste à un délai entre l'appui sur la poignée et l'envoi de la puissance pour "simuler" un patinage à l'accélération.

Ca peut s'essayer, mais ca risque de commencer à faire pas mal de traitement entre les envois d'information à la PB, va falloir faire du code très très propre !!!

fretz a écrit :
T'as raison pour les PIT-STOP, vaut mieux ptet rester simple comme c'est prévu pour une utilisation avec enfants. Peut-être pourrais-tu juste différencier les actions PLEIN/REPARATION avec leur vitesse d'exécution : un plein se fait plus vite que des réparations ?...

fretz a écrit :
Je sais pour l'avoir lu que ce n'est pas le même protocole pour la C7030 (et PB-PRO) et la C7042. Apriori la vitesse de transfert des infos de puissance et autres est bcp plus élevée sur la C7042 ce qui permet entre autres de faire un frein variable qui n'est pas possible avec la C7030 (c'est tout ou rien). Ca voudrait dire qu'actuellement ton soft n'est pas compatible avec les anciennes PB6 Il faudrait que tu récupères les sources du protocole c'est ça ? Bon techniquement ça doit être possible puisque "SSDC V5" propose le choix entre les 3 versions de PowerBase.

Arf, oui c'est galère ça. En fait chaque protocole nécessite d'être implémenté, même si une grosse partie des traitements est générique. Le souci des protocoles c'est qu'il faut les tester et pour les tester il faut avoir le matos correspondant... J'ai une PB6 7030 mais pas le cable... j'ai pas de PB Pro.
Hier j'ai passé un bon moment à travailler sur les pacer à tour variable. Je m'arrache les cheveux sur un souci qui se présente de temps en temps. au bout d'un moment le pacer devient dingue il y a un décalage qui se crée et du coup les phases d'accélérations se font en plein virage plutot qu'en sortie. Je n'ai pas encore trouvé pourquoi ni comment réglé le souci. J'ai l'impression que c'est du au positionnement de la PB (donc des capteurs de fin de course). Sur ma piste la PB est en bout de ligne droite donc quand on enregistre le tour on arrive à bloc sur la PB et c'est ca qui mettrait le bazar. A priori si j'enregistre un tour "sage" je n'ai pas de souci de décalage. En gros il me reste encore des astuces à trouver pour que les pacers variables fonctionnent dans tous les cas de figure.

NNKClinton a écrit :
C'est toi le programmeur altruiste et de génie ... Tu développes bien ce que tu veux, comme tu veux, sur ce que tu veux, et au rythme que tu veux ...

dd32 a écrit :

fretz a écrit :
Pour la phase d'accélération je pensais juste à un délai entre l'appui sur la poignée et l'envoi de la puissance pour "simuler" un patinage à l'accélération.

dd32 a écrit :
Ca peut s'essayer, mais ca risque de commencer à faire pas mal de traitement entre les envois d'information à la PB, va falloir faire du code très très propre !!!

Vaut ptet mieux se limiter à une action sur le frein pour l'instant alors

dd32 a écrit :

fretz a écrit :
T'as raison pour les PIT-STOP, vaut mieux ptet rester simple comme c'est prévu pour une utilisation avec enfants. Peut-être pourrais-tu juste différencier les actions PLEIN/REPARATION avec leur vitesse d'exécution : un plein se fait plus vite que des réparations ?...

dd32 a écrit :
C'est le cas, les réparations vont moins vite (30 % moins vite environ).

dd32 a écrit :
Arf, oui c'est galère ça. En fait chaque protocole nécessite d'être implémenté, même si une grosse partie des traitements est générique. Le souci des protocoles c'est qu'il faut les tester et pour les tester il faut avoir le matos correspondant... J'ai une PB6 7030 mais pas le cable... j'ai pas de PB Pro. Hier j'ai passé un bon moment à travailler sur les pacer à tour variable. Je m'arrache les cheveux sur un souci qui se présente de temps en temps. au bout d'un moment le pacer devient dingue il y a un décalage qui se crée et du coup les phases d'accélérations se font en plein virage plutot qu'en sortie. Je n'ai pas encore trouvé pourquoi ni comment réglé le souci. J'ai l'impression que c'est du au positionnement de la PB (donc des capteurs de fin de course). Sur ma piste la PB est en bout de ligne droite donc quand on enregistre le tour on arrive à bloc sur la PB et c'est ca qui mettrait le bazar. A priori si j'enregistre un tour "sage" je n'ai pas de souci de décalage. En gros il me reste encore des astuces à trouver pour que les pacers variables fonctionnent dans tous les cas de figure.

Dommage (pour moi ) mais bon finalise déjà le soft pour la C7042, tu pourras toujours implémenter ptet plus tard la version C7030 si tu n'as vraiment plus rien à faire
Un logiciel qui communique par liaison série avec un système embarqué en temps réel ça peut déjà soulever quelques bugs coriaces
Je réitère mes vœux pour le débogage !

Plus sérieusement tu dis que sur un tour "sage" t'as pas le pb. Sur un tour plus "violent", est-ce que tu fais déraper ton PACER ? Il suffit d'un dérapage involontaire pour que ta consigne soit décalée de quelques dixièmes. Et il est difficile de reproduire une même glissade tour après tour !
Au niveau du protocole lors du passage sur les capteurs de la PB, est-ce que c'est la PB qui envoie l'info ou c'est toi qui la questionne régulièrement "est-ce qu'une voiture est passée sur les capteurs ?". Dans le 1er cas je pensais ptet à un délai de traitement et donc à un décalage de l'info qui serait plus pénalisant pour la synchro du PACER lorsqu'il va plus vite ?
Ou différemment exprimé: la PB n'enverrait pas l'info en temps réel du passage sur les capteurs ?

Je cherche d'éventuelles pistes à ton pb...

Concernant le pacer, pour avancer sur le souci j'ai commencé par prendre une auto avec aimant histoire de ne pas avoir le souci de "dérapage" qui effectivement décale tout.

Le principe de communication avec la PB est assez simple, c'est une communication bi directionnelle continue.
La PB envoie l'info de ce qu'il se passe en piste et moi en retour je lui dit ce qu'elle doit faire.
Il y a 37 réceptions de message par seconde et 37 envois.
Quand une auto passe la ligne, le message suivant que la PB envoi contient l'id de la voiture et le chrono du tour.
C'est clairement la que tout se joue.
Pour le moment, ma "technique" pour la gestion d'un Pacer variable est de conserver tous les échanges PC -> PB d'un tour (tour témoin en gros) et de les reproduire à chaque tour.
J'ai ajouté à ça un ajustement dynamique de la vitesse en fonction du chrono cible du tour témoin pour palier à l'usure des tresses ou courant qui passe moins bien etc. En gros l'idée est que si le tour réalisé est moins bon que le tour témoin, il faut augmenter un peu la cadence (facile a dire mais moins facile à mettre en oeuvre).

Les questions que tu te posent sont les bonnes (je pense...) je me suis posé les mêmes.
Pour moi il faudrait que je déplace ma pb en début de ligne droite plutot qu'en fin (zone de freinagne sensible) mais je peux pas le faire simplement, il faudrait que je démonte pas mal de choses. Pour le moment j'essaye d'optimiser au maximum mon code pour limiter les effets néfastes et après je passerais au décalage de la PB, au moins pour confirmer ou infirmer l'hypothèse.
Quoi qu'il en soit, le sujet est hyper sympa à traiter mais bon je peux pas faire ça la journée malheureusement...

Youpi !!!

Après une semaine à chercher et essayer différentes choses, j'ai fini par trouver.
Bon en gros la base scalex "pête un plomb" (ok c'est une analyse primaire pour l'instant !) au bout d'un certain temps.
En gros la base contient un timer de course, pour une raison que je ne comprend pas encore, au bout d'environ 100 secondes la base envoi les informations différemment à la piste ce qui provoquait un gros décalage au niveau du pacer.
Je réinitialise le timer de la base avant son "pétage de plomb" et tout est ok.
C'est un peu délire comme truc et je me demande si c'est ma PowerBase qui est buguée ou si ce comportement est général...
Quoi qu'il en soit, le chantier "Pacer intelligent" est pratiquement bouclé maintenant. Par contre j'ai quand même du me résoudre à utiliser des voitures avec aimant car il y a des choses que l'on ne peut pas gérer.
Au bout d'un certain nombre de tour l'auto change en terme de comportement, les pneus se salissent, les tresses aussi, le frein moteur évolue sensiblement etc.
Du coup cela devient très compliqué d'éviter des petits décalages dans les phases d'accélération et de freinage. Avec une auto sans aimant, le moindre petit décalage, même infime peut provoquer une sortie de piste.
J'ai quand même fait faire 30 tours à une GT 40 Slot.it (sans aimant) avec des tours à 0.3s / 0.4s du record de la piste, mais pour cela il faut faire un "tour témoin" très propre et très coulé.

Bon, quoi qu'il en soit, l'algorithme évoluera encore dans le temps pour améliorer le comportement mais la déjà on a une bonne base de départ pour faire des courses contre une auto à vitesse variable.
Les limites actuelles du système :
- pas possible de faire changer le pacer de voie sinon il risque d'être perdu.
- Un pacer ne peut pas s'arrêter au stand, du coup il ne consomme pas de fuel et n'est pas concerné par l'usure de la voiture. Donc si on roule contre lui on a un désavantage important si on veut utiliser la gestion du fuel et des dégâts.

Pour ce dernier point, si vous avez des idées je suis preneur !

David