Idées de fonctionnalités

Voici des idées de fonctionnalités sans ordre spécifique. Cette liste contient des fonctionnalités que nous pensons importantes et qui peuvent apporter de bonnes contributions à ROS 2. Veuillez nous contacter avant de creuser dans une nouvelle fonctionnalité. Nous pouvons vous conseiller et vous mettre en contact avec d’autres développeurs.

Concept design

  • Format IDL

    • Tirez parti de nouvelles fonctionnalités telles que le regroupement de constantes en énumérations

    • Étendez l’utilisation aux fichiers .idl avec juste des constantes et/ou déclarez des paramètres avec des plages

    • Revoir les contraintes de nommage de l’interface IDL, voir ros2/design#220

  • Créer un plan de migration pour la transition ROS 1 -> ROS 2

  • Unicité des noms de nœuds, voir ros2/design#187

  • « API » spécifique d’un nœud en termes de sujets/services/etc. dans un format descriptif, voir ros2/design#266

Infrastructures et outils

  • Bâtiment

  • Documentation

    • Obsolète https://design.ros2.org. Le contenu doit être déplacé vers un REP, vers https://github.com/ros2/ros2_documentation, ou être supprimé.

    • Correction du générateur de documentation par package pour pouvoir documenter les artefacts de construction, c’est-à-dire les messages, les services, les actions, etc.

    • Assurez-vous que https://docs.ros.org/en/ros2_documentation se reconstruit automatiquement lors des modifications apportées à https://github.com/ros2/ros2_documentation.

    • documentation ``principale””

    • Ajoutez des exemples de documentation sur l’utilisation de ROS 2 avec les blocs-notes Jupyter.

    • Ajouter de la documentation pour la mise en œuvre d’un nouveau RMW.

    • Fournissez trois types de contenu différents :

      • « démos » pour montrer les fonctionnalités et les couvrir de tests

      • « exemples » pour montrer une utilisation simple/minimaliste qui pourrait avoir plusieurs façons de faire quelque chose

      • « tutoriels » qui contiennent plus de commentaires et d’ancres pour le wiki (enseigner une méthode recommandée)

Nouvelles fonctionnalités

Les étoiles en queue indiquent l’effort approximatif : 1 étoile pour petit, 2 étoiles pour moyen, 3 étoiles pour grand.

  • Améliorations de la journalisation [* / **]

    • Configuration spécifiée dans un fichier

    • Configuration par enregistreur (activation par exemple de rqt_logger_level)

  • Lié au temps

    • Taux d’assistance et sommeil en fonction de l’horloge

  • Fonctionnalités supplémentaires de l’API Graph [** / ***]

    • Introspecter le paramètre QoS pour tous les sujets (en particulier à distance)

    • à l’API maître ROS 1 : https://wiki.ros.org/ROS/Master_API

    • Notification basée sur les événements

    • Nécessite la connaissance de l’interface rmw qui doit être étendue

  • Exécuteur

    • Améliorations des performances (principalement autour du jeu d’attente)

    • Ordonnancement déterministe (ordonnancement équitable)

    • Découpler les attentes

  • Génération de messages

    • Génération de messages de rattrapage pour les langues non prises en charge prêtes à l’emploi

    • Modifiez les noms de champs dans le message pour éviter les mots-clés spécifiques à la langue

    • Améliorez les performances du générateur en les exécutant dans le même interpréteur Python

  • Lancement

    • Prise en charge du lancement d’exécutables multi-nœuds (c’est-à-dire composition manuelle)

    • Extension de la prise en charge XML/YAML de lancement : événements et gestionnaires d’événements, espaces de noms de balises et alias

  • Rosbag

    • Soutenir les services d’enregistrement (et les actions)

  • ros1_bridge

    • Soutenir les actions passerelles

  • Configuration RMW

    • Méthode standard unifiée de configuration du middleware

  • Remappage [** / ***]

    • Remappage et alias dynamique via une interface de service

  • Masquage de type [***]

  • Développer la sécurité en temps réel [***]

    • Pour les services, les clients et les paramètres

    • Exposez davantage de paramètres de qualité de service liés aux performances en temps réel

    • Messagerie intra-processus sécurisée en temps réel

  • Fonctionnalités et démonstrations multi-robots [***]

    • Indésirable que tous les nœuds de tous les robots partagent le même domaine (et se découvrent)

    • Concevoir comment « partitionner » le système

  • Prend en charge plus d’implémentations DDS/RTPS :

    • RTI Connext DDS Micro (implémenté, non activé par défaut ou officiellement pris en charge).

  • Améliorations de la sécurité :

    • Plus de granularité dans la configuration de la sécurité (autoriser l’authentification uniquement, l’authentification et le chiffrement, etc.) [*]

    • Intégrer le plug-in de journalisation DDS-Security (manière unifiée d’agréger les événements de sécurité et de les signaler aux utilisateurs via une interface ROS) [**]

    • Sécurité du stockage des clés (actuellement, les clés sont simplement stockées dans le système de fichiers) [**]

    • Interface plus conviviale (facilite la spécification de la configuration de sécurité). Peut-être une interface graphique Qt ? Cette interface graphique pourrait également aider à distribuer les clés d’une manière ou d’une autre. [***]

    • Une façon de dire « s’il vous plaît sécuriser ce système en cours d’exécution » avec une interface utilisateur qui générerait automatiquement des clés et des politiques pour tout ce qui est en cours d’exécution. [***]

    • S’il existe des fonctionnalités spécifiques au matériel pour sécuriser les clés ou accélérer le chiffrement/la signature des messages, cela pourrait être intéressant à ajouter aux implémentations DDS/RTPS qui ne l’utilisent pas déjà. [***]

Réduction de la dette technique

  • Correction des tests floconneux sur https://ci.ros2.org/view/nightly.

  • Capacité à exécuter (tous) les tests unitaires avec des outils, par ex. valgrind, clang-tidy, analyse statique clang (scan-build), ASAN, TSAN, UBSAN, etc.

  • Examen des API, en particulier des API destinées aux utilisateurs dans rclcpp et rclpy

  • Refactoriser l’API rclcpp dans des packages séparés axés sur un seul aspect, rclcpp devrait ensuite toujours fournir l’API combinée destinée à l’utilisateur

  • Revisitez les répartiteurs de messages, envisagez d’utiliser std :: polymorphic_allocator pour résoudre les problèmes

  • Synchroniser/réconcilier design docs avec l’implémentation.

  • Adresser/classer les tickets en attente

  • Adresser les TODO dans le code / docs

  • Supprimer tinyxml en tant que dépendance