Structure de données pour repérage dans l'espace

a marqué ce sujet comme résolu.

Bonjour,

Dans le cadre de mon projet Tartopum, il me faut repérer un tracteur dans un verger. Comme vous pouvez le lire ici, ce dernier est découpé en rangs, lesquels sont alors partagés en zones.

Par souci de flexibilité, je souhaiterais ne pas imposer de méthode de localisation. On pourra donc passer par les coordonnées GPS, par une distance à une borne fixe, par celle au début du rang, par une numérotation des pommiers… Ainsi, l'utilisateur est libre d'attacher les informations qu'il souhaite à ses zones (exemple) puis d'implémenter son propre module de localisation capable, en lisant la carte et en recevant des informations sur la position (GPS, distance…), d'en déduire la zone courante.

Seulement, cela fonctionne bien dans le cas où le verger a une structure bien définie : découpé en rangs rectilignes. Mais comment pourrais-je m'y prendre si je ne souhaite pas faire d'hypothèse sur la structure du verger ? Le considérer comme un rectangle auquel on appliquerait un maillage serait-il une bonne méthode ? En existe-t-il une universelle ?

Merci !

+0 -0

Bonjour !

Tiens, c'est amusant comme projet ! C'et au passage une très bonne idée de laisser le système de repérage au choix de l'utilisateur, surtout avec les balises RTK qui commencent à se standardiser dans ce milieu ! (ça peut mener à de l'automatisation au final)

Concernant la localisation : à priori, tu peux complètement séparer le système de localisation de la zone potentielle où il peut être, et le système de localisation est donc seulement chargé de renvoyer l'indice de la zone, comme tu le fais sûrement déjà.

Ensuite, les systèmes de localisation, il en existe pas non plus des masses, tu as principalement 2 types de fonctionnement : - Coordonnées (absolues, relative, peu importe, tu as un point qui se déplace dan un espace) => ici, la forme la plus adaptée parait être un maillage, ou alors faire des associations polygones/zones (qui est sensiblement plus simple à modéliser informatiquement). - Passage (capteur infrarouge, caméra - sans calcul de la position précise, capteurs …) : là par contre, ça paraît beaucoup trop de définir des polygones, mais tu peux conserver le même fonctionnement quand même (le polygone peut même permettre de voir la couverture du capteur).

DU coup,si tu souhaites quelque chose de flexible, les polygones me paraissent bien plus adapté à toute utilisation (sauf si tu commences à empiler des pommiers, mais à la limite, là encore tu peux t'en sortir en rajoutant une information de hauteur dessus), ça te permet de garder la structure en rectangle, c'est facile à manipuler, et tu peux même te servir du sujet de l'exo 5 du Prologin de cette année (avec une triangulation de Delaunay) pour placer au mieux tes capteurs !

(bon, la fin n'est peut être pas forcément utile, au fond).

Je ne pense pas que tu ais besoin de plus, tu réponds à tous les problèmes qui étaient posés avec ça. Ceux qui peuvent venir vont surtout être de l'ordre de la représentation : ordre de grandeur, mise en place de ces polygones, etc, et c'est plus des choix que des contraintes sur ton programme.

Par contre, ça va être galère à représenter graphiquement (pour l'UI). Peut-être devrais-je laisser ça à l'utilisateur ? Ou alors, il faudrait qu'il me fournisse une fonction permettant de convertir les données attachées à une zone en une position dans le plan.

+0 -0

Tout dépend de comment tu veux présenter ca. Dessiner des polygones, en soi, c'est plus simple que de dessiner un maillages, et le soucis est surtout au niveau de la représentation et du sens qu'elle doit prendre, mais tu peux aussi rajouter des éléments comme des obstacles, des arbres ou des points nommés pour donner ce sens. Mais c'est exactement la même problématique et ca m'a l'air d'être des problèmes independants (sauf si ton projet s'oriente vers de la topologie de terrain, mais ca m'étonnerait que ce soit la bonne époque pour faire ca dans l'agriculture).

Je me demandais : pourquoi des polygones ? Un carré devrait suffire, non ?

Pour la représentation, je parle simplement d'un truc comme ça, pour que l'utilisateur ait une vue sur sa position :

Image utilisateur

De plus, la carte permet à l'utilisateur de fournir des informations au module de localisation. Par exemple, si, pour un rang donné, je repère ma position en fonction de la distance parcourue depuis une extrémité du rang fixée, la carte fournit une interface pour indiquer dans quel rang on se situe.

D'autre part, mon histoire de sens direct/indirect n'a plus de… sens. Comment gérer l'orientation du tracteur ?

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte