Projet Tripmaster : cahier des charges

longueur de trajets donnés comme liste de coordonnées

Lorsque j'ai une liste de coordonnées, j'utilise une bibliothèque Python

Code: 
from pyproj import Geod
import numpy as np

Ensuite je choisis l'ellipsoïde WGS84

Code: 
g = Geod(ellps='WGS84')

Je mets les longitudes dans un tableau lon et les latitudes dans un tableau lat, et j'appelle la fonction de calcul des distances. Attention à l'ordre des arguments, c'est lon avant lat. Pas comme dans google maps.

Code: 
azimuth,azimuth_oppose,distances = g.inv(lon,lat)

Pour optenir la distance totale, je somme les distances

Code: 
d = distances.sum()

Qui sait comment enlever la ligne blanche affichée en bas de chaque code ?
 
liste de coordonnées à partir des identificateurs OpenStreetMap

Losrqu'on j'ai collecté une liste d'identificateurs de "Nodes" d'une carte OpenSteetMap, par exemple manuellement comme décrit au post 624 http://prius-touring-club.com/vbf/showpost.php?p=198300 j'utilise une bibliothèque Python pour récupérer les coordonnées dans la carte OSM ou PBF.

Code: 
from imposm.parser import OSMParser

Je prépare un dictionnaire des morceaux de route et un dictionnaire des coordonnées

Code: 
WAYS = {}
COORDS = {}

Il faut définir des fonctions "callback" qui vont remplir mes dictionnaires au fur et à mesure de la lecture du fichier carte

Code: 
def waysfun(ways):
    for osmid, tags, refs in ways:
        WAYS[osmid] = (tags, refs)

def coordsfun(coords):
    for x in coords:
        assert (len(x) == 3)
        COORDS[x[0]] = (x[1],x[2])

On lance la lecture

Code: 
p = OSMParser(ways_callback=waysfun, coords_callback=coordsfun)
p.parse('ZR3.osm')

Je fournis une liste "refs" de morceaux de chemins, puis je récupère les coordonnées

Code: 
nrefs = len(refs)
lat = np.zeros(nrefs, np.float)
lon = np.zeros(nrefs, np.float)
for i,n in enumerate(refs):
    lon[i] = float(COORDS[0])
    lat[i] = float(COORDS[1])

Ensuite il faut couper le bon morceau de route pour y placer un point tel que le point de départ de coordonnées "latlon" connu. J'ai construit la fonction "getinterval" qui trouve le noeud caractérisant le segment à couper dans le morceau de route OpenStreetMap

Code: 
def getinterval(lat,lon,latlon):
    n = len(lon)
    assert len(lat) == n
    az,azm,dist = g.inv(latlon[1]*np.ones(n),latlon[0]*np.ones(n),lon,lat)
    daz = np.mod(np.diff(az)+180.,360.)-180.
    v = np.nonzero(np.abs(daz) > 90.)[0]
    assert(v.size == 1)
    return v[0]

Mais là ça devient très technique...
 
Trop. Je n'arrive pas à suivre.
Mais tu as repondu à ma question :
tu fais toi même le tracé dans meurisse à la main.

Combien de temps cela te prend pour 20 km ?

J'ai de mon coté automatisé en utilisant les api google map
Je donne des points qui me garantissent que le trajet sera le bon, et pas un raccourci
et je lance une macro excel qui me donne les coordonnées de tous les points du tracé google

à partir de ces points j'en fait 2 choses :
une analyse des courbures de la route grâce à des formules excel et une macro excel
la récupération des images streetview du tracé et leur affichage comme un film grâce à un programme tripmasterviewer ; qui profite des données de courbure pour m'annoncer les virages et les zones possibles d'accélération comme un copilote.
 
Le tracé meurisse à la main, je ne l'ai fait que pour comparer avec le tracé automatique venant de la carte OSM. J'ai voulu jouer manuellement à couper les virages ou non. C'est un peu long, une vingtaine de minutes peut-être.

Croiser les résultats OSM et google peut être intéressant.
 
Voici un lien vers les tracés des différentes ZR
https://docs.google.com/file/d/0B_Oh2yu8mH9pekMtSXIzbkN5RnM/edit?usp=sharing

Il y a 3 tableaux qui se suivent dans un fichier

Le premier est le point de départ des calculs
en première colonne les coordonnées des points de référence du tracé
en deuxième colonne du texte commentaire du point
la troisième colonne est l'url de l'api qui permet de récupérer le tracé entre deux points
les colonnes suivantes sont celles que m'a donné Less pour que je fasse mes calculs
seule la colonne 1 est nécessaire pour ma macro excel

Cette macro fabrique la troisième colonne du tableau 1

Puis va interroger google pour récupérer le tracé entre deux points en lançant chacune des urls de la colonne 3 de tableau 1

Cela fabrique le tableau2 qui est un résumé de chacun des retours d'Url
Le retour est un ensemble de sections, et pour chaque section google nous donne une liste de points encodée que tu retrouves en colonne 6 du tableau 2, que je décode en colonne 7. J'en profite pour noter le temps en seconde et la durée en metre de ce tracé (colonnes 8 et 9), et les commentaires de google pour cette section, que je mets en colonne 10

Ce tableau 2 est donc suffisant pour comparer tes données par OSM et les miennes par Google.

La tableau 3 est l'affichage de tous ces points en colonnes, puis des calculs pour déterminer la courbure et préparer le travail de tripmaster viewer qui va aller me chercher à partir de ce CSV et m'afficher comme dans un film les images Street View de google, tout en jouant le copilote en m'annonçant les prochains virages et zones d'accélération

Il serait intéressant de comparer les deux traces car celles de google présentent des "anomalies" que peut-être OSM ne génére pas. Ce qui pourrait nous encourager à utiliser OSM pour cette partie.
 
Je ferai ce soir la comparaison des ZR. J'ai juste regardé la position du panneau de départ de la ZR3. C'est bien celle que j'imaginai.

PS

- Je suis très honoré de voir ces pages en orange, n'étant plus passager clandestin mais membre stagiaire.

- J'ai rêvé cette nuit que j'avais mis du E85 dans le réservoir et que ma P2 est tombée en panne. C'est grave docteur ?
 
:grin: Ben, les Zamis, au train où vous allez, je vous vois trés bien connecter
le bazard à la direction, accélérateur et freins.....et vogue la Prius....!
 
Carte des points de géodésie officiels

Intéressant site qui permet de trouver tous les points de géodésie en France :

http://geodesie.ign.fr/fiches/index.php?module=e&action=visugeod

Exemple de fiche pour un point situé sur la ZR4 : http://geodesie.ign.fr/fiches/pdf/IP.C.N3-80_388057.pdf

Il y a la photo du point, son altitude et ses coordonnées. Attention, il s'agit des coordonnés GRS 80, qui peuvent différer légèrement des coordonnées WGS84. Il y a aussi mention du point kilométrique, mais on a vu que celui-ci ne vaut rien pour nous.
 
Routage sur OSM en ligne

J'ai testé le service de routage en ligne http://openrouteservice.org/

On peut directement donner les informations du chemin dans l'adresse. Par exemple pour le ZR3 avec les points intermédiaires de thierryb, cela donne
http://openrouteservice.org/index.p...80782 6.519362,43.785998&pref=Fastest&lang=fr

La réponse est parfois lente.

Une fois que le chemin est tracé, on peut télécharger la succession des coordonnées sous forme de fichier XML.

Le code suivant m'a donné pour la longueur de ce chemin 20.078 km

Code: 
import os
from lxml import etree
import numpy as np
from pyproj import Geod

"""
fichier XML récupéré de
http://openrouteservice.org/index.php?start=6.577477,43.775093&end=6.51245,43.844303&via=6.544242,43.764405%206.520858,43.76708%206.52096,43.780782%206.519362,43.785998&pref=Fastest&lang=en
C'est parfois lent.

"""
tree = etree.parse(os.path.join(os.environ['HOME'],'L/P/www.acm.mc/2013/zr3_route.xml'))
# r1010 = tree.getroot()[1][0][1][0] # "brute force !"
r1010 = r\
    .find('{http://www.opengis.net/xls}Response')\
    .find('{http://www.opengis.net/xls}DetermineRouteResponse')\
    .find('{http://www.opengis.net/xls}RouteGeometry')\
    .find('{http://www.opengis.net/gml}LineString')
npos = len(r1010)

lon = np.zeros(npos, np.float)
lat = np.zeros(npos, np.float)

for i,e in enumerate(r1010):
    lonlat = e.text.strip().split()
    lon[i] = float(lonlat[0])
    lat[i] = float(lonlat[1])

g = Geod(ellps='WGS84')
az,azn,d = g.inv(lon[:-1],lat[:-1],lon[1:],lat[1:])

print("distance = {:.3f} km".format(d.sum()*1e-3))

L'API google donne 48 m de moins. Dans le même langage :

Code: 
from urllib2 import urlopen
import simplejson

googleapi = 'http://maps.googleapis.com/maps/api/directions/json'
points = ('43.775093,6.577477', '43.764405,6.544242', '43.76708,6.520858','43.780782,6.52096','43.785998,6.519362','43.844303,6.51245')

d = 0
for i in range(len(points)-1):
    results = simplejson.load(urlopen('%s?origin=%s&destination=%s&sensor=false' % (googleapi, points[i], points[i+1])))
    assert (results['status'] == 'OK')
    print ''
    for route in results['routes']:
        print route['summary']
        for leg in route['legs']:
            print 'D : %s @ %s' % (leg['start_address'], leg['start_location'])
            print 'A : %s @ %s' % (leg['end_address'], leg['end_location'])
            print 'Distance : %s and Durée: %s' % (leg['distance'], leg['duration'])
            d += int(leg['distance']['value'])
print '\nDistance totale : {:.3f}'.format(0.001*d)
 
Réflexions de Litaire...

Bonsoir les super-développeurs et avant toute chose bravo pour vos travaux !
J'avoue que je suis à la fois un peu rebuté par la complexité de la chose et en même temps je "bois" vos compte-rendus de recherches qui me fascinent.

Etant (à ce jour) partant pour participer au RMCEN 2014, et n'ayant pas une approche aussi pointue que la vôtre, ne possédant pas de PC (désolé je n'ai que du Mac, ne m'accablez pas svp), n'ayant plus de P2 mais une Auris HSD 1ère génération, bref ayant un "bagage" technique peu évolué et aucun matériel si ce n'est la voiture (ce qui en soi semble être néanmoins une bonne base), je vous serai gré de ne pas m'en vouloir de vous exposer ma stratégie (tout du moins ses prémices) pour la prochaine édition :

J'ai constaté que l'organisateur semblait avoir des failles dans la mesure des distances, mais qu'il était néanmoins "souverain" sur le jugement et classement qu'il doit malgré tout asseoir sur les données en sa possession et faisant foi.

Votre outil et méthodes sont indéniablement supérieurs en terme de précision au sien : ne craignez-vous pas qu'il induise une marge d'erreur risquant d'aller à l'encontre du but recherché, l'écart de mesure par excès pouvant devenir handicapante ?

Le roadbook indique des points de passage "remarquables" : une reconnaissance indispensable sur le terrain avec repérage sur la carte + photo "souvenir" (intégrée ensuite au roadbook "maison") et enregistrement du temps idéal à ce point de passage (selon les indications de vitesse moyenne à respecter fournies juste avant la spéciale) en fonction de la distance entre points me semble être une méthode certes basique mais fiable, et qui devrait être en phase avec les mesures retenues par l'organisation.

Je serais donc tenté d'utiliser un tripmaster plutôt "classique" (cf. le Crisartech RR100 signalé par Palm35, ou bien le Pack Rallye de Chronopist par ex. -ce que Blondeau semble avoir-) en gérant des recalages préprogrammés sur la base du roadbook au fur et à mesure de l'avancement dans la ZR.

Quant à la navigation hors ZR on a vu qu'un simple iPhone avec la petite application Rallye Timer était largement suffisante, voire tout simplement l'étude du parcours, une carte, une calculette et un chrono ou une montre.

Un autre élément est la monte pneumatique du véhicule : la régularité étant la base, les ralentissements et accélérations imposés par les virages sont à limiter au maximum, un pneu qui a du grip permet de mieux passer les courbes à condition que le châssis suive (et le pilote aussi...).
L'inconvénient est qu'il sera moins économe en carburant, mais quelles sont les performances que l'on retient d'une telle course ?...
Ce type de pneu doit pouvoir convenir et il a l'avantage d'être homologué route : chez Toyo -155 € le morceau-, chez Yokohama - je ne sais pas le prix exact, mais plus cher je crois-, pour ne citer que ces 2 là...

Et bien sûr il est indispensable de bosser et re-bosser le road-book sur des cartes papier, de se le mettre en tête et aller sur le terrain...

Si je confirme mon engagement je demanderai par ex. à Less s'il veut bien me communiquer le road-book des 3 ZR dans le Vercors de l'édition 2011, elles ne sont plus accessibles sur le site ACM, ceci pour aller m'entrainer et valider mes procédures.
L'idéal serait de pouvoir confronter nos méthodes et résultats, car vous avez l'expérience mais la mauvaise idée pour quasi vous tous d'habiter loin, j'ai le Vercors à 10' de la maison mais pas d'expérience de pilote, et... pas encore de co-pilote en vue ! Il serait absurde de ne pas avoir le même copilote pour l'épreuve que pour l'entraînement.

Voilà où j'en suis de mes réflexions, il me reste aussi à monter mon budget/financement que j'estime à environ 3500 € pour l'équipage complet (inscription, 1 train de pneus, tripmaster, assurance complémentaire pour l'auto, carburant et autoroute A/R, bouffe et hotels +, petit équipement complémentaire, cartes, ...), somme à affiner.

Désolé pour le HS partiel et mon approche plus empirique que scientifique, mais je tenais à vous en faire part.

PS. 1 : je n'ai pas eu le temps ni le courage de tout relire de votre post, il se peut que j'aie évoqué des points déjà pris en compte et/ou validés ou non par vous, désolé pour le doublonnage...

PS. 2 : dans mes recherches je suis tombé sur ce topic où il est question d'une approche d'un outil très semblable au vôtre... Il semblerait que le développeur se soit concentré sur son appareil plus "classique" et n'ait pas trop donné suite à la version PC...
 
Non, je ne crois pas qu'il puisse y avoir un excès de qualité de mesure handicapant. Ce que je compte faire, c'est 1) refaire les mesures de distance sur les ZR passés, typiquement à faible vitesse, et en repointant la position des chronométreurs. Mais il faut qu'on me fournisse les films qui permettent de repérer ces positions. J'espère en déduire la méthodologie des organisateurs. 2) reconnaitre les ZR l'an prochain pour faire un relevé précis de la route, avec l'échelle de mesure des organisateurs, en supposant que c'est la même que cette année. Au fait, ces ZR sont bien définies un mois à l'avance ? 3) construire un système qui mesure le trajet en course, avec un recalage automatique sur les virages pour que la précision reste de 10 m, même si le style de conduite change (accélérations, freinages, virages coupés).

Pour les pneus, il me semble que les bons pilotes tels que Less soient capables de travailler avec des pneus qui adhèrent plutôt mal, puisque gonflés au max. admissible.
 
En fait, il y aura toujours une erreur liée au fait que nous ne savons pas comment les organisateurs comptent les distances et le temps de passage.
Mais avoir un moyen d'être "reproductible" doit permettre d'être dans la moyenne des bonnes équipes. Et si nous avons plusieurs voitures, nous finirons par comprendre.
Blondeau arrive à un niveau de précision très élevé. Ce n'est pas un hasard. Il a compris comment les organisateurs procédaient et a compris comment reproduire cela dans son cockpit pendant la course. Mais il n'a pas voulu me le dire l'année dernière.
Pour atteindre un niveau élevé, il faut recaler avec une mesure physique indépendante de notre conduite pendant la course, de si on coupe ou pas un virage, ou autre. D'ailleurs, c'est la condition pour être capable de traiter un incident de course : devoir faire marche arrière sur un pont pour laisser passer un véhicule en face, ou une panne temporaire du tripmaster. La reconnaissance en live est probablement la bonne méthode. Et cela ne doit pas être un hasard dans le succès de Less cette fois-ci. Comme je ne suis pas sur que nous aurons l'envie et le temps de faire des recos réelles, les recos virtuelles avec Google ou OSM peuvent être un moyen acceptable.
Ensuite comment recaler en course : Less pensait utiliser les bornes mais elles étaient sous la neige parfois, kinetik compte utiliser les mouvements du volant, et moi le gps. Je pense que nous ferons les trois si nous arrivons à mettre au point nos trois méthodes, et à être capable de les appliquer en course, et Less et JB pourront témoigner des difficultés rencontrées dans les premières ZR pour se mettre au point dans cette tache. Mais je n'ai pas de doute sur le fait que nous allons y arriver, et même peut-être l'automatiser en grande partie avec un contrôle du copilote. Il y entre ceux directement concernés et ceux qui nous lisent parfois suffisamment de têtes bien faites.
 
Les reconnaissances c'est certainement utile pour les pilotes, mais c'est je crois indispensable pour le calibrage du parcours. Mais un calibrage suffit pour tout le monde. Si c'est un mois à l'avance, j'ai bien envie de le faire.
 
Palm35 à dit:
Pouvez vous tester vos théories ... pouvez vous notamment vérifier la distance trouvée ?
Cliquez pour agrandir...

Bon, il ne va pas s'agir de théorie ici :oops: La théorie qu'il faudra faire, c'est celle de la méthode de mesure des organisateurs pour le positionnement des points de contrôle, comparée à la mesure des points initiaux et finaux et à la mesure de la zone d'étalonnage.

Ce que tu demandes c'est de faire des comparaisons entre une zone d'étalonnage et les cartes.

Avec les cartes, on définit une succession de points, puis on calcule la distance, en supposant qu'on fait des lignes droites entre chaque points. On pourrait raffiner avec des courbes de Bézier ou autres. Il faudrait aussi tenir compte de la pente, qui allonge les distance réelles.

Les points sont caractérisés par des coordonnées sur une représentation de la terre. Depuis l'avènement du GPS, on utilise plutôt WGS84.

Ton parcours dit qu'il faut partir de N 42º 51’ 49” = 42+(51 + 49/60.)/60. = 42.863611 ; W 2º 38’ 43” = -(42+(38 + 43/60.)/60.) = -2.645278

Je peux retoucher ces coordonnées de diverses manières. Je donne l'écart au point choisi pour la suite. On voit que le point des organisateurs est très éloigné du point des cartes satellites. 23 m trop au sud et 23 m trop à l'est = 33 m de distance.

typelatitudelongitudeécart [m]
Instructions42.86361-2.6452833
Vision satellite42.86383-2.645533
Street-View42.86379-2.645534
Bing42.86379-2.645506
Bing calé sur route OSM42.86382-2.645560


Enfin, il faut arriver ici :

N 42º 51’ 00” = 42+(51 + 0/60.)/60. = 42.85000 ; W 2º 38’ 55” = -(42+(38 + 55/60.)/60.) = -2.64861
Le point est 17 m trop au sud et 1 m trop à l'est = 17 m de distance.

typelatitudelongitudeécart [m]
Instructions42.85000-2.6486117
Vision satellite42.85023-2.648619
Street-View42.85019-2.648615
Bing42.85018-2.648613
Bing calé sur route OSM42.85015-2.648620


Pour trouver les coordonnées OSM rapidement, je passe par le serveur http://openrouteservice.org/

Je donne les points

Pos@: -2.64556 42.86382
Pos@: -2.613296 42.860081
Pos@: -2.64862 42.85015

J'exporte en XML, et mon code 011_distance_openrouteservice_org.py donne 6.737 km, soit 7 mètres de plus que les organisateurs.
 
Dernière édition:
kinetik à dit:
Ce que tu demandes c'est de faire des comparaisons entre une zone d'étalonnage et les cartes.
Cliquez pour agrandir...

Oui, c'est cela que je voulais dire...
Le principal c'est que tu aies compris ce que je demandais.
On attends la réaction de Less, et on vous tient au jus...
 
Je suis d'accord, la théorie est fondamentale
Cela permet de faire de bonne expérimentation.
Puis raffiner la théorie
Puis...

J'irai voir l'outil
Je n'ai eu des problèmes que dans la ZR5 ou 6
C'est pourquoi cela m'intéresse d'avoir d'autres sources, comme OSM
 
thierryb à dit:
La première version 630 est née. Et elle supporte le MBED.
J'abandonne ma 710.

Il faudrait quand même que je vérifie que l'odblink marche toujours.
Et je pourrais aussi la rendre compatible P3, Auris et autre
Si priusfan nous aide, et si certains préfèrent utiliser un truc de Andy en bluetooth, j'essaierai aussi de rendre cette version compatible.

Je vais accumuler des données de comparaison 0B4, 230, GPS, Google
Je vais permettre d'attribuer une vitesse cible par tronçon d'un parcours, et m'entraîner à rouler à 0s

J'ai désormais quelques parcours cadencés tous les 300 m environ : maison-paris, et retour, maison -boulot et retour, périphe intérieur et extérieur.
Je vais surement ajouter la A86, l'A1, l'A13.
J'en ajouterai au fur et à mesure de mes déplacements

Je vais surement désactivé le top gps à l'arrêt

Maintenant que j'ai le MBED, je vais remettre la conso
Et surement intégrer la puissance Kinetik sur le tronçon, pour voir si la variation de distance est liée à la puissance (idée de planétaire).

Et il faudrait que l'on revoit nos specs pour ZR et CH et autres cas particuliers.
Less et Palm, l'année prochaine commence maintenant.
Cliquez pour agrandir...

La 630c est prete, maintenant que je peux travailler plus facilement en utilisant ma tablette sous Windows 8.

Je viens d'implémenter l'attribution d'une vitesse, en fait d'un délai pour faire un tronçon d'une certaine distance, avec une succession de tronçon. Cela va me permettre de faire des ZR tout le temps, et en plus de traiter d'autres types de rallyes de régularité qui découpent une ZR en plusieurs tronçons, avec des vitesses différentes sur chaque tronçon.
Cette méthode devrait aussi permettre de traiter les CH entre les ZR.

Je viens aussi d'implémenter le fait que le top GPS ne se fasse pas à l'arret quand je suis prêt d'un point.

J'ai mis la conso, comme cela nous allons maintenant savoir au microlitre combien il reste dans notre réservoir. Et accessoirement connaitre la conso par tronçon. Cela pourrait aussi permettre d'avoir plus de données pour améliorer ma conduite hypermiling.

Il me manque la puissance kinétik sur le tronçon, mais la conso en microlitre est équivalente, à la limite de la conso electrique.

J'ai ajouté un selecteur de fichier pour passer facilement d'un tracer à un autre. Je pourrais envisager la même chose pour le selecteur de points de recalibrage.

Je dois automatiser le saut de points de recalibrage : détecter que le point n'a pas été pris, et mettre automatiquement le suivant qui est devant moi pour du recalibrage. Cela m'arrive quand le point prévu est sous un pont. J'ai en parti déjà automatisé, sauf qu'il faut que j'active manuellement la recherche. Il ne me reste qu'à automatiser l'activation.

Mes conclusions :
Je suis sûr que le recalibrage GPS est a un sens, comme le recalibrage par rapport à une reconnaissance. Il faudrait que j'améliore l'affichage pour que cela soit facile de l'utiliser en ZR. Aujourd'hui j'affiche des choses, mais je ne sais pas l'utiliser.

Pour un calibrage, il faut plusieurs choses :
- la distance de reconnaissance (Google ou réelle) et la distance officielle du Rallye. Puis il faut supposer que nous nous trompons en tout point du chemin de la même façon. C'est le moins pire des hypothèses, tant que l'on ne sait pas comment procèdent les officiels. C'est en tous les cas mieux que de supposer que le coefficient calculé entre la zone d'étalonnage officielle et la reconnaissance de la zone d'étalonnage sera le même pour tout le reste du parcours.
- il faut des points sur ce parcours dont la distance est connue par rapport à notre étalonnage (soit Google, soit réel). Pour chacun de ces points en connaitre les coordonnées GPS.
Ensuite le recalibrage se fait quand on passe sur un point, c'est que l'on est à une distance connue, qu'il faut corriger avec le coefficient de correction de ce tronçon. Et le top de ce point peut se faire soit manuellement, comme a tenté de le faire Less pendant le dernier Rallye, à condition que la neige n'ait pas caché ses points de repere; ou en utilisant notre coordonnée gps.

Avoir un gps à 10hz est donc important si l'on veut un calibrage automatique. Avec un à 1 hz, la précision du recalibrage pourrait être de 1 à 3 secondes.

Je ferai aussi des essais pour voir si la vitesse de la voiture ne peut pas avoir un impact sur le recalibrage et comment la compenser. Je m'interroge sur ce point, car j'ai parfois des données bizarres, qui portent sur une trentaine de metres parfois, et je ne sais pas pourquoi.
 
Bon, pas mal de bug. Certains corrigés.
Mais il reste du boulot.

Ce qui marche :
- les consos
cela ne sert à rien pour le rallye, ou si peu. Mais cela me manquait depuis que j'étais passé de la version 710 à la version 630. C'est fait. Il ne me manque presque plus rien.
- le passage à un nouveau tronçon de manière automatique GPS ou manuellement, avec calcul de la vitesse moyenne, de la distance à parcourir sur ce tronçon.

Par contre le décompte du temps ne marche plus du tout sauf la prise en compte du passage à un nouveau tronçon, et j'ai aussi cassé les affichages de Less. J'espère que cela sera résolu avant dimanche soir.
 
Enfin, cela semble marcher.
J'ai pu me faire une ZR dans ma ville.
Mais j'ai du revoir les temps proposés par Google.
Je pense que je vais ajouter dans le carré magique la vitesse demandée, la distance restante avec cette vitesse, et la prochaine vitesse demandée. Pour pouvoir anticiper.

Maintenant, il faudrait que je regarde si je peux faire confiance au top gps par rapport au top manuel, et aussi mesurer l'impact d'un top décalé.

J'oubliais, les affichages de Less remarchent.

Je vais maintenant modifier le programme MBED pour qu'il crache les mêmes données en bluetooth et usb comme cela le copilote et le pilote pourront recevoir les mêmes données, mais les analyser, ou réagir différemment.
 
hello
dupliquer la sortie bt vers usb est très simple...

pour info, regardez ce que fait un un leafman avec un mbed et 2 écrans...
cela se passe ici et le détail est là

ce gars là est un vrai développeur :jap: . dans son code, j'ai remarqué un truc intéressant: il neutralise temporairement les interruptions de réception CAN lorsqu'il veut avoir la paix.
 
Less, car tu es le plus concerné, avec moi.
J'aimerais que tu vérifies.
Même si cela semble marcher.
Cela peut aboutir à un saut de temps au moment du passage d'un point, pour rattraper l'écart de distance entre l'odo de la Prius et la distance théorique donnée par les organisateurs jusqu'à ce point

Voici ce que j'ai fait pour les points de repere :
Quand j'arrive sur un point de repere, je toppe le point, ou c'est toppé automatiquement
A tout moment, je connais la distance parcourue Dc (c comme courant) depuis le dernier top.
Je sais que pour atteindre le prochain top je dois faire une certaine distance Dr (r comme référence) dans un certain temps Tr
Donc je devrais être à Tc = Tr x Dc / Dr en temps du dernier top
Et donc depuis le début à Tc = Tc + somme(tous les Tr avant ce point)
Soit Ta (a comme actuel) le temps passé depuis le début de la ZR
Si j'étais pile poil : Tc = Ta
Si Ta > Tc alors j'ai pris mon temps et je dois accélérer
Si Ta < Tc, alors je suis allé trop vite, et je dois ralentir

Kinetik, et les autres, vous pouvez vérifier aussi.

Je pourrais aussi compenser automatiquement l'écart entre la distance théorique et la distance odo, en calculant au fur et à mesure un coefficient multiplicateur entre le mesuré et le théorique. Ce coefficient serait égal pour le premier point au coefficient calculé sur la zone d'étalonnage. Mais tout le parcours servirait au fur et à mesure d'étalonnage.
Qu'en dis-tu Less, Kinetik, et les autres ?

J'oubliais : avoir la vitesse en dixième de km/h c'est chouette pour rester dans le dixième de seconde.
 
Identifiez-vous ou inscrivez-vous pour participer.
Pages vues depuis le 20 Oct 2005: 312,136,549
Retour
Haut Bas