Message du forum

[Dépannage OpenArm] La planification échoue en raison d'une inadéquation entre le modèle de collision et la géométrie réelle (avancé)

Le planificateur rejette les chemins sûrs ou autorise les chemins risqués ? Réconcilier la scène avec la réalité avant de blâmer les algorithmes du planificateur.

Forum / Index des messages / Bras ouvert

Poste

Un problème de planification frustrant avec OpenArm apparaît lorsque le robot, les outils ou les accessoires changent dans le monde réel, mais que la scène de la planification croit toujours à une géométrie plus ancienne. Les chemins échouent sans raison claire ou semblent sûrs lors de la planification tout en coupant quelque chose de réel.

Comment diagnostiquez-vous les échecs de planification des mouvements d'OpenArm causés par des modèles de collision qui ne correspondent pas à la géométrie réelle du robot ou de l'espace de travail ?

Veuillez partager la façon dont vous comparez les maillages de collision à la réalité, détectez la géométrie des outils obsolètes et validez que le planificateur utilise une scène digne de confiance avant de blâmer le planificateur lui-même.

Si vous répondez, incluez un symptôme de planification exact et une vérification exacte de la géométrie ou de la scène qui a révélé l'inadéquation.

Chemin de dépannage associé : Saturation de couple et pointes de courant sous charge · Gigue d'état commun et oscillation à basse vitesse

Module : OpenArm · Public : constructeurs-intégrateurs · Type : question

Tags : bras ouvert, planification de mouvement, modèle de collision, géométrie

Commentaire 1

Contexte avancé : Le planificateur n'arrêtait pas de rejeter les tracés à proximité d'un coin d'étau, même si le jogging manuel indiquait un jeu réel de 12 à 15 mm. Le symptôme semblait aléatoire jusqu'à ce que nous comparions la géométrie de la scène prévue avec le matériel actuel des outils.

Commentaire 2

Contexte avancé : Ce qui l'a exposé, c'est la superposition du nuage de points en direct et du maillage de collision dans RViz. Le maillage de la bride de l'outil était obsolète d'environ 12 mm en X après un changement d'accessoire, le planificateur évitait donc correctement un obstacle fantôme.

Commentaire 3

Contexte avancé : Notre approbation porte désormais sur 50 trajectoires rejouées dans une scène actualisée plus deux sondes de dégagement physique dans la région la plus étroite. Si l’un ou l’autre échoue, nous bloquons le déploiement et reconstruisons les actifs de collision.

Commentaire 4

Suivi contextuel avancé : Question de suivi pour les équipes avancées : lorsque la scène et la réalité divergent, contrôlez-vous le déploiement sur des métriques de distance nuage de points-maillage, et quelle distance maximale autorisez-vous ?

Sélecteur rapide de symptômes

Choisissez votre symptôme le plus proche pour suivre le bon chemin de dépannage.

Pas encore sélectionné.

FAQ rapide

Comment puis-je prouver que la géométrie de la scène est obsolète ?

Superposez un nuage de points en direct et un maillage de collision autour des zones à dégagement restreint et inspectez les décalages systématiques.

python tools/export_scene_mesh.py --out scene_mesh.ply
python tools/compare_cloud_to_mesh.py --cloud live_scan.pcd --mesh scene_mesh.ply
Que devrait faire le déploiement pour les équipes avancées ?

Exiger une relecture de la trajectoire ainsi que des sondes de dégagement physique ; bloquer la libération en cas de violation du seuil de distance de maillage.

Puis-je copier ces commandes telles quelles ?

Utilisez-les d’abord comme modèle de liste de contrôle. Confirmez les noms d’interface, les identifiants d’appareils et les conditions de sécurité dans votre propre cellule avant l’exécution.